Should guix track package aliases?

Should guix track package aliases?

[Josh Marshall]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

I'm starting to collect software that needs packaging, and one thing I'm
running into is that naming conventions between the source project, various
distros, and guix itself have some drift.  Something which seems low effort
but would ease translating between various nomenclatures would be to track
package aliases.  These would be non-canonical in guix, but like shells
sometimes making suggestions as to what program you might have intended to
type would make life easier.

The approach which I think makes the most sense is to add an optional but
encouraged field in package definitions which takes a list of alternative
package names.  When using `guix search` this field could also be
evaluated, and when `guix package -i` is invoked and the target does not
exist, these aliases could be searched through for similar names to the
non-existing target and suggest the actual package they might have intended.

This appears that it could be low effort, not interfere with any commands,
not really change the interface, and make life easier.  Anybody have any
thoughts as to whether this would be a good idea or not?

[-- Attachment #2: Type: text/html, Size: 1216 bytes --]

Re: Should guix track package aliases?

[Nikita Gillmann]

Hi,

I'm not sure if that's something guix needs to be aware of.
If the name differs very much and guix naming conventions differ plus it
can not be found through any of the fields, it makes sense. But you
probably don't want to track the different conventions used by various
package managers as it is not really low-effort without knowing written
and unwritten conventions and where to find them.

just my initial thoughts on this, knowing a fair share of PMs.

Josh Marshall transcribed 2.5K bytes:
> I'm starting to collect software that needs packaging, and one thing I'm
> running into is that naming conventions between the source project, various
> distros, and guix itself have some drift.  Something which seems low effort
> but would ease translating between various nomenclatures would be to track
> package aliases.  These would be non-canonical in guix, but like shells
> sometimes making suggestions as to what program you might have intended to
> type would make life easier.
> 
> The approach which I think makes the most sense is to add an optional but
> encouraged field in package definitions which takes a list of alternative
> package names.  When using `guix search` this field could also be
> evaluated, and when `guix package -i` is invoked and the target does not
> exist, these aliases could be searched through for similar names to the
> non-existing target and suggest the actual package they might have intended.
> 
> This appears that it could be low effort, not interfere with any commands,
> not really change the interface, and make life easier.  Anybody have any
> thoughts as to whether this would be a good idea or not?

Re: Should guix track package aliases?

[zimoun]

Dear,

On Sat, 9 May 2020 at 22:19, Josh Marshall
<joshua.r.marshall.1991@gmail.com> wrote:

> [...] naming conventions between the source project, [...] , and guix itself have some drift.

Some packages already track upstream name: see the field '(proprieties
(upstream-name . "foo"))', e.g., the package "r-flowsom",

> The approach which I think makes the most sense is to add an optional but encouraged field in package definitions which takes a list of alternative package names.  When using `guix search` this field could also be evaluated, and when `guix package -i` is invoked and the target does not exist, these aliases could be searched through for similar names to the non-existing target and suggest the actual package they might have intended.

Well, the 'proprieties' field is not used by 'package->recutils' which
is the function used by "guix show" (and "guix search").  I do not
have an option if an extra field "upstream-name" should be added or
not.

However, from my point of view, "Explicit is better than implicit." as
said any good Zen. ;-)
So, I appears to me a bad idea to implicitly install 'bar' when I type
"guix package -i foo" because 'bar' is an alternative name I am not
aware of.

IMHO, the fix is to improve the synposis and the description to be
able to reach the expected package.  If the description is
well-written, then "guix search bar" should return the package "foo".


Well, do you have specific example in mind?


All the best,
simon

Re: Should guix track package aliases?

[Vincent Legoll]

On 09/05/2020 22:18, Josh Marshall wrote:
> This appears that it could be low effort, not interfere with any 
> commands, not really change the interface, and make life easier.  
> Anybody have any thoughts as to whether this would be a good idea or not?

What about the following:

------------>8-----------------------8<--------------------------------

# default to list guix things without --all
$ guix rosetta [--package|-p] truc-bidule
machin-chose (guix)

# Show available translations with --all
$ guix rosetta --package|-p [--all|-a] truc-bidule
bidule-chouette (ubuntu)
bouzin (freebsd)
machin-chose (guix)
truc-bidule (debian) <- this one being also added by --all
trucmuche (centos)
truc-machin (fedora, rhel)

# default to list guix things without --all
$ guix rosetta [--service|-s|--daemon] systemctl restart THING
herd restart THING

# Show available translations with --all
$ guix rosetta [--service|-s|--daemon] [--all|-a] herd status THING
systemctl status THING (systemd)
rcctl check THING (4.4BSD rc)
/etc/init.d/THING status (sysv-init)

# default to list guix things without --all
$ guix rosetta [--command|-c] yum search THING
guix search THING

# Show available translations with --all
$ guix rosetta [--command|-c] [--all|-a] yum install
guix package -i (guix official)
guix install (guix alias)
apt-get install (debian official)
apt install (debian alias)
yum install (centos)
dnf install (fedora, rhel)

$ guix rosetta [--help|-h]
guix rosetta [--help|-h] [--package|-p] [--command|-c] [--all|-a] THING*
Rosetta stone to help translation of various things between unix dialects.

The default mode is to only show translation targeting guix.

--help|-h             Show this help
--all|-a              Show all available translations for THING
--command|-c          Show package manager command translations
--service|-s|--daemon Show service, daemon manager translations
--package|-p          Show package names translations

This tool is only giving fuzzy answers that may not be fully accurate.

------------>8-----------------------8<--------------------------------

This would go lovely along the guix foreign distro installer.

I'm only (but still only) half-joking, this is a tool I'd have
loved to have on multiple occasions, often not on guix.

Used googl often being used to approximate it, crudely but effectively.

I'm not starting to work on it though, but I'd gladly help anyone
who do.

-- 
Vincent Legoll

Re: Should guix track package aliases?

[Julien Lepiller]

Le 10 mai 2020 05:57:22 GMT-04:00, zimoun <zimon.toutoune@gmail.com> a écrit :
>Dear,
>
>On Sat, 9 May 2020 at 22:19, Josh Marshall
><joshua.r.marshall.1991@gmail.com> wrote:
>
>> [...] naming conventions between the source project, [...] , and guix
>itself have some drift.
>
>Some packages already track upstream name: see the field '(proprieties
>(upstream-name . "foo"))', e.g., the package "r-flowsom",
>
>> The approach which I think makes the most sense is to add an optional
>but encouraged field in package definitions which takes a list of
>alternative package names.  When using `guix search` this field could
>also be evaluated, and when `guix package -i` is invoked and the target
>does not exist, these aliases could be searched through for similar
>names to the non-existing target and suggest the actual package they
>might have intended.
>
>Well, the 'proprieties' field is not used by 'package->recutils' which
>is the function used by "guix show" (and "guix search").  I do not
>have an option if an extra field "upstream-name" should be added or
>not.
>
>However, from my point of view, "Explicit is better than implicit." as
>said any good Zen. ;-)
>So, I appears to me a bad idea to implicitly install 'bar' when I type
>"guix package -i foo" because 'bar' is an alternative name I am not
>aware of.

The proposal was about suggesting anotger nameqwhen no package was found, not to install something else.

>
>IMHO, the fix is to improve the synposis and the description to be
>able to reach the expected package.  If the description is
>well-written, then "guix search bar" should return the package "foo".
>
>
>Well, do you have specific example in mind?
>

$ guix install gcc
guix install: error: gcc: unknown package
Hint: did you mean `guix install gcc-toolchain`?

Since not being able to install gcc is surprising, and you don't always know about gcc-toolchain.

$ guix install gpg
Hint: did you mean `guix install gnupg`?

Often a name is used to refer to a package, and it's annoying to go through a search, especially when you have to filter a big output.

I'd use the search when I don't have a specific package in mind. For instance, looking for a font or a game:

guix search roguelike
"Give me a list of roguelike games"
guix search font japanese
"Give me a list of fonts I can use to see Japanese texts"

If I have to do "guix search gpg" I really mean "give me the package named gpg but you stupid guix devs in your infinite wisdom have decided to use another name" ;)

The first use-case is good, the second one is frustrating, don't you think?

>
>All the best,
>simon

Re: Should guix track package aliases?

[zimoun]

Hi Vincent,

On Sun, 10 May 2020 at 12:08, Vincent Legoll <vincent.legoll@gmail.com> wrote:

> Used googl often being used to approximate it, crudely but effectively.

The big question is how to build such database.
Wikidata?

All the best,
simon

Re: Should guix track package aliases?

[zimoun]

Hi Julien,

On Sun, 10 May 2020 at 14:13, Julien Lepiller <julien@lepiller.eu> wrote:

> The proposal was about suggesting anotger nameqwhen no package was found, not to install something else.

Sorry I misinterpreted.


> >Well, do you have specific example in mind?
>
> $ guix install gcc
> guix install: error: gcc: unknown package
> Hint: did you mean `guix install gcc-toolchain`?
>
> Since not being able to install gcc is surprising, and you don't always know about gcc-toolchain.

I understand even if this one is the wrong example. :-)
It even deserves an entry in the manual.
Well, but I understand what you mean.


> $ guix install gpg
> Hint: did you mean `guix install gnupg`?

The question is: why do you type 'gpg'?

I mean, the upstream name is really GnuPG so it is not one "stupid"
Guix devs arbitrary rename because in their infinite wisdom they
decided to. ;-)

Well, do you type 'gpg' because
a) it is the name of the binary?
or b) it is the name of the package in your previous favourite distro?

If it is a), then a proposal by Pierre named "filesearch" is floating
around.  And this should improve the situation.

If it is b), then I do not see how to improve the situation in the
general case.  But maybe there is some well-known cases.


> Often a name is used to refer to a package, and it's annoying to go through a search, especially when you have to filter a big output.

I agree.  From my point the issue is that "guix search" is not doing
the job and the improvement should come from this.  And your 'gpg'
example is a good one, IMHO:

--8<---------------cut here---------------start------------->8---
$ guix search gpg | recsel -C -p name,relevance
name: signing-party
relevance: 16
name: qgpgme
relevance: 15
name: libgpg-error
relevance: 14
name: python2-gpg
relevance: 11
name: python-gpg
relevance: 11
name: ledger-agent
relevance: 9
name: python2-pygpgme
relevance: 8
name: python-pygpgme
relevance: 8
name: gpgme
relevance: 8
name: kgpg
relevance: 6
name: jetring
relevance: 6
name: emacs-pinentry
relevance: 6
name: trezor-agent
relevance: 5
name: python-trezor-agent
relevance: 5
name: keepkey-agent
relevance: 5
name: qtpass
relevance: 2
name: pinentry
relevance: 2
name: pinentry-tty
relevance: 2
name: pinentry-qt
relevance: 2
name: pinentry-gtk2
relevance: 2
name: pinentry-gnome3
relevance: 2
name: pinentry-emacs
relevance: 2
name: pinentry-efl
relevance: 2
name: kleopatra
relevance: 2
name: gnupg
relevance: 2
name: gnupg
relevance: 2
name: git-remote-gcrypt
relevance: 2
name: gajim
relevance: 2
name: emacs-extend-smime
relevance: 2
name: assword
relevance: 2
--8<---------------cut here---------------end--------------->8---

The expected package 'gnupg' appears... piouf!

I fully agree that the experience with "guix search" is frustating.
And maybe using both the 'upstream-name' and an extra 'properties'
such as 'alternative-names' or 'extra-keywords' should help for
discoverability.


WDYT?

All the best,
simon

Re: Should guix track package aliases?

[Josh Marshall]

[-- Attachment #1: Type: text/plain, Size: 3915 bytes --]

This back and forth is what I've been having going on in my head.  We might
be able to leverage repology.org for their work on mapping packages across
distros.  Yesterday, civodul entered a bug to remove the Etag and
last-modified headers in the nginx config to fix a bug on our side so
repology will update info on guix.  That code is GPL'd so some of it could
be incorporated, and maybe even be leveraged to interpret foreign distro's
packages to create package prototypes which we could then use to more
rapidly expand what packages are available through guix.  I could see this
as a high-payoff medium effort development for guix.

On Sun, May 10, 2020 at 9:34 AM zimoun <zimon.toutoune@gmail.com> wrote:

> Hi Julien,
>
> On Sun, 10 May 2020 at 14:13, Julien Lepiller <julien@lepiller.eu> wrote:
>
> > The proposal was about suggesting anotger nameqwhen no package was
> found, not to install something else.
>
> Sorry I misinterpreted.
>
>
> > >Well, do you have specific example in mind?
> >
> > $ guix install gcc
> > guix install: error: gcc: unknown package
> > Hint: did you mean `guix install gcc-toolchain`?
> >
> > Since not being able to install gcc is surprising, and you don't always
> know about gcc-toolchain.
>
> I understand even if this one is the wrong example. :-)
> It even deserves an entry in the manual.
> Well, but I understand what you mean.
>
>
> > $ guix install gpg
> > Hint: did you mean `guix install gnupg`?
>
> The question is: why do you type 'gpg'?
>
> I mean, the upstream name is really GnuPG so it is not one "stupid"
> Guix devs arbitrary rename because in their infinite wisdom they
> decided to. ;-)
>
> Well, do you type 'gpg' because
> a) it is the name of the binary?
> or b) it is the name of the package in your previous favourite distro?
>
> If it is a), then a proposal by Pierre named "filesearch" is floating
> around.  And this should improve the situation.
>
> If it is b), then I do not see how to improve the situation in the
> general case.  But maybe there is some well-known cases.
>
>
> > Often a name is used to refer to a package, and it's annoying to go
> through a search, especially when you have to filter a big output.
>
> I agree.  From my point the issue is that "guix search" is not doing
> the job and the improvement should come from this.  And your 'gpg'
> example is a good one, IMHO:
>
> --8<---------------cut here---------------start------------->8---
> $ guix search gpg | recsel -C -p name,relevance
> name: signing-party
> relevance: 16
> name: qgpgme
> relevance: 15
> name: libgpg-error
> relevance: 14
> name: python2-gpg
> relevance: 11
> name: python-gpg
> relevance: 11
> name: ledger-agent
> relevance: 9
> name: python2-pygpgme
> relevance: 8
> name: python-pygpgme
> relevance: 8
> name: gpgme
> relevance: 8
> name: kgpg
> relevance: 6
> name: jetring
> relevance: 6
> name: emacs-pinentry
> relevance: 6
> name: trezor-agent
> relevance: 5
> name: python-trezor-agent
> relevance: 5
> name: keepkey-agent
> relevance: 5
> name: qtpass
> relevance: 2
> name: pinentry
> relevance: 2
> name: pinentry-tty
> relevance: 2
> name: pinentry-qt
> relevance: 2
> name: pinentry-gtk2
> relevance: 2
> name: pinentry-gnome3
> relevance: 2
> name: pinentry-emacs
> relevance: 2
> name: pinentry-efl
> relevance: 2
> name: kleopatra
> relevance: 2
> name: gnupg
> relevance: 2
> name: gnupg
> relevance: 2
> name: git-remote-gcrypt
> relevance: 2
> name: gajim
> relevance: 2
> name: emacs-extend-smime
> relevance: 2
> name: assword
> relevance: 2
> --8<---------------cut here---------------end--------------->8---
>
> The expected package 'gnupg' appears... piouf!
>
> I fully agree that the experience with "guix search" is frustating.
> And maybe using both the 'upstream-name' and an extra 'properties'
> such as 'alternative-names' or 'extra-keywords' should help for
> discoverability.
>
>
> WDYT?
>
> All the best,
> simon
>

[-- Attachment #2: Type: text/html, Size: 4865 bytes --]

Re: Should guix track package aliases?

[Josh Marshall]

Checking http://guix.gnu.org/packages.json again, it seems like the
server changes to not misrepresent dates have not been applied yet.
Can someone get in and do that?

On Sun, May 10, 2020 at 2:16 PM Josh Marshall
<joshua.r.marshall.1991@gmail.com> wrote:
>
> This back and forth is what I've been having going on in my head.  We might be able to leverage repology.org for their work on mapping packages across distros.  Yesterday, civodul entered a bug to remove the Etag and last-modified headers in the nginx config to fix a bug on our side so repology will update info on guix.  That code is GPL'd so some of it could be incorporated, and maybe even be leveraged to interpret foreign distro's packages to create package prototypes which we could then use to more rapidly expand what packages are available through guix.  I could see this as a high-payoff medium effort development for guix.
>
> On Sun, May 10, 2020 at 9:34 AM zimoun <zimon.toutoune@gmail.com> wrote:
>>
>> Hi Julien,
>>
>> On Sun, 10 May 2020 at 14:13, Julien Lepiller <julien@lepiller.eu> wrote:
>>
>> > The proposal was about suggesting anotger nameqwhen no package was found, not to install something else.
>>
>> Sorry I misinterpreted.
>>
>>
>> > >Well, do you have specific example in mind?
>> >
>> > $ guix install gcc
>> > guix install: error: gcc: unknown package
>> > Hint: did you mean `guix install gcc-toolchain`?
>> >
>> > Since not being able to install gcc is surprising, and you don't always know about gcc-toolchain.
>>
>> I understand even if this one is the wrong example. :-)
>> It even deserves an entry in the manual.
>> Well, but I understand what you mean.
>>
>>
>> > $ guix install gpg
>> > Hint: did you mean `guix install gnupg`?
>>
>> The question is: why do you type 'gpg'?
>>
>> I mean, the upstream name is really GnuPG so it is not one "stupid"
>> Guix devs arbitrary rename because in their infinite wisdom they
>> decided to. ;-)
>>
>> Well, do you type 'gpg' because
>> a) it is the name of the binary?
>> or b) it is the name of the package in your previous favourite distro?
>>
>> If it is a), then a proposal by Pierre named "filesearch" is floating
>> around.  And this should improve the situation.
>>
>> If it is b), then I do not see how to improve the situation in the
>> general case.  But maybe there is some well-known cases.
>>
>>
>> > Often a name is used to refer to a package, and it's annoying to go through a search, especially when you have to filter a big output.
>>
>> I agree.  From my point the issue is that "guix search" is not doing
>> the job and the improvement should come from this.  And your 'gpg'
>> example is a good one, IMHO:
>>
>> --8<---------------cut here---------------start------------->8---
>> $ guix search gpg | recsel -C -p name,relevance
>> name: signing-party
>> relevance: 16
>> name: qgpgme
>> relevance: 15
>> name: libgpg-error
>> relevance: 14
>> name: python2-gpg
>> relevance: 11
>> name: python-gpg
>> relevance: 11
>> name: ledger-agent
>> relevance: 9
>> name: python2-pygpgme
>> relevance: 8
>> name: python-pygpgme
>> relevance: 8
>> name: gpgme
>> relevance: 8
>> name: kgpg
>> relevance: 6
>> name: jetring
>> relevance: 6
>> name: emacs-pinentry
>> relevance: 6
>> name: trezor-agent
>> relevance: 5
>> name: python-trezor-agent
>> relevance: 5
>> name: keepkey-agent
>> relevance: 5
>> name: qtpass
>> relevance: 2
>> name: pinentry
>> relevance: 2
>> name: pinentry-tty
>> relevance: 2
>> name: pinentry-qt
>> relevance: 2
>> name: pinentry-gtk2
>> relevance: 2
>> name: pinentry-gnome3
>> relevance: 2
>> name: pinentry-emacs
>> relevance: 2
>> name: pinentry-efl
>> relevance: 2
>> name: kleopatra
>> relevance: 2
>> name: gnupg
>> relevance: 2
>> name: gnupg
>> relevance: 2
>> name: git-remote-gcrypt
>> relevance: 2
>> name: gajim
>> relevance: 2
>> name: emacs-extend-smime
>> relevance: 2
>> name: assword
>> relevance: 2
>> --8<---------------cut here---------------end--------------->8---
>>
>> The expected package 'gnupg' appears... piouf!
>>
>> I fully agree that the experience with "guix search" is frustating.
>> And maybe using both the 'upstream-name' and an extra 'properties'
>> such as 'alternative-names' or 'extra-keywords' should help for
>> discoverability.
>>
>>
>> WDYT?
>>
>> All the best,
>> simon

Re: Should guix track package aliases?

[zimoun]

Dear Josh,

On Sun, 24 May 2020 at 21:26, Josh Marshall
<joshua.r.marshall.1991@gmail.com> wrote:
>
> Checking http://guix.gnu.org/packages.json again, it seems like the
> server changes to not misrepresent dates have not been applied yet.
> Can someone get in and do that?

I am not sure to understand what you mean and what you are asking for.

Well, http://guix.gnu.org/packages.json is generated every X minutes
(or hour) by [1].

[1] http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/apps/packages/builder.scm#n128

HTH,
simon

Re: Should guix track package aliases?

[Josh Marshall]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

Hi Zimoun,

The HTTP headers of the page indicate that the file hasn't changed since
1970.  This is a bug.  That incorrect date breaks repology.org trying to
track guix packages.

On Mon, May 25, 2020, 06:42 zimoun <zimon.toutoune@gmail.com> wrote:

> Dear Josh,
>
> On Sun, 24 May 2020 at 21:26, Josh Marshall
> <joshua.r.marshall.1991@gmail.com> wrote:
> >
> > Checking http://guix.gnu.org/packages.json again, it seems like the
> > server changes to not misrepresent dates have not been applied yet.
> > Can someone get in and do that?
>
> I am not sure to understand what you mean and what you are asking for.
>
> Well, http://guix.gnu.org/packages.json is generated every X minutes
> (or hour) by [1].
>
> [1]
> http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/apps/packages/builder.scm#n128
>
> HTH,
> simon
>

[-- Attachment #2: Type: text/html, Size: 1690 bytes --]

Re: Should guix track package aliases?

[Nicolò Balzarotti]

Hello everybody,
It has been fixed today
https://issues.guix.gnu.org/issue/37207

Repology data is now updated

Nicolò

Josh Marshall <joshua.r.marshall.1991@gmail.com> writes:

> Hi Zimoun,
>
> The HTTP headers of the page indicate that the file hasn't changed since
> 1970.  This is a bug.  That incorrect date breaks repology.org trying to
> track guix packages.
>
> On Mon, May 25, 2020, 06:42 zimoun <zimon.toutoune@gmail.com> wrote:
>
>> Dear Josh,
>>
>> On Sun, 24 May 2020 at 21:26, Josh Marshall
>> <joshua.r.marshall.1991@gmail.com> wrote:
>> >
>> > Checking http://guix.gnu.org/packages.json again, it seems like the
>> > server changes to not misrepresent dates have not been applied yet.
>> > Can someone get in and do that?
>>
>> I am not sure to understand what you mean and what you are asking for.
>>
>> Well, http://guix.gnu.org/packages.json is generated every X minutes
>> (or hour) by [1].
>>
>> [1]
>> http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/apps/packages/builder.scm#n128
>>
>> HTH,
>> simon
>>

Re: Should guix track package aliases?

[Josh Marshall]

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

Checking out repology.org/repository/gnuguix , it got picked up and guix
looks like it is in much better shape.

On Mon, May 25, 2020, 08:04 Nicolò Balzarotti <anothersms@gmail.com> wrote:

>
> Hello everybody,
> It has been fixed today
> https://issues.guix.gnu.org/issue/37207
>
> Repology data is now updated
>
> Nicolò
>
> Josh Marshall <joshua.r.marshall.1991@gmail.com> writes:
>
> > Hi Zimoun,
> >
> > The HTTP headers of the page indicate that the file hasn't changed since
> > 1970.  This is a bug.  That incorrect date breaks repology.org trying to
> > track guix packages.
> >
> > On Mon, May 25, 2020, 06:42 zimoun <zimon.toutoune@gmail.com> wrote:
> >
> >> Dear Josh,
> >>
> >> On Sun, 24 May 2020 at 21:26, Josh Marshall
> >> <joshua.r.marshall.1991@gmail.com> wrote:
> >> >
> >> > Checking http://guix.gnu.org/packages.json again, it seems like the
> >> > server changes to not misrepresent dates have not been applied yet.
> >> > Can someone get in and do that?
> >>
> >> I am not sure to understand what you mean and what you are asking for.
> >>
> >> Well, http://guix.gnu.org/packages.json is generated every X minutes
> >> (or hour) by [1].
> >>
> >> [1]
> >>
> http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/apps/packages/builder.scm#n128
> >>
> >> HTH,
> >> simon
> >>
>

[-- Attachment #2: Type: text/html, Size: 2700 bytes --]

Re: Should guix track package aliases?

[Vincent Legoll]

Hello,

On 25/05/2020 16:20, Josh Marshall wrote:
> Checking out repology.org/repository/gnuguix 
> <http://repology.org/repository/gnuguix> , it got picked up and guix 
> looks like it is in much better shape.

Yay, but we're still far from the front page's top repositories...

But, to celebrate our come back into the fray, I've grabbed a few low
hanging fruits from the outdated and/or potentially vulnerable list.

Series incoming (on guix-patches, issue #41533)...

-- 
Vincent Legoll

Re: Should guix track package aliases?

[Josh Marshall]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

I could fix up some of the new homepages.  We've already seen some Gnu
related package losses like gdal.  I think SWH adoption for packages may
want to be moved from as packages are added to as packages are updated --
just to have a regular, low overhead, but still slow move to SWH.

On Mon, May 25, 2020, 17:57 Vincent Legoll <vincent.legoll@gmail.com> wrote:

> Hello,
>
> On 25/05/2020 16:20, Josh Marshall wrote:
> > Checking out repology.org/repository/gnuguix
> > <http://repology.org/repository/gnuguix> , it got picked up and guix
> > looks like it is in much better shape.
>
> Yay, but we're still far from the front page's top repositories...
>
> But, to celebrate our come back into the fray, I've grabbed a few low
> hanging fruits from the outdated and/or potentially vulnerable list.
>
> Series incoming (on guix-patches, issue #41533)...
>
> --
> Vincent Legoll
>

[-- Attachment #2: Type: text/html, Size: 1428 bytes --]

Re: Should guix track package aliases?

[zimoun]

Dear Josh,

On Tue, 26 May 2020 at 00:31, Josh Marshall
<joshua.r.marshall.1991@gmail.com> wrote:

> I could fix up some of the new homepages.  We've already seen some Gnu related package losses like gdal.  I think SWH adoption for packages may want to be moved from as packages are added to as packages are updated -- just to have a regular, low overhead, but still slow move to SWH.

What do you mean by "losses like gdal"?

BTW, if the method of package origin is 'git-fetch' then "guix lint"
should automatically queue the package to SWH.  And I guess that the
Data Service or CI is linting, whatever the package is added or
updated.
The file 'sources.json' is updated every X minutes (or hours) and the
SWH fetcher should be ready really soon.  And once this 'url-fetch'
from SWH is on production, a lot of packages will move to SWH.


Well, considering SWH, what is missing today IMHO on the Guix side is
UI, e.g., display using "guix weather" if the package is in SWH or
not, display a chart on the Data Service to represent which percentage
is in SWH, maybe move the {package,source}-json-builder from the
website engine to "guix publish", etc..  Help welcome. :-)


All the best,
simon

Re: Should guix track package aliases?

[Josh Marshall]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

For gadl, it was that the gal website hosting it went down.  With regards
to pre-commit hooks, just to make sure each commit message conforms to what
is expected and is best practice for PRs and commits for the project.

On Mon, May 25, 2020, 19:15 zimoun <zimon.toutoune@gmail.com> wrote:

> Dear Josh,
>
> On Tue, 26 May 2020 at 00:31, Josh Marshall
> <joshua.r.marshall.1991@gmail.com> wrote:
>
> > I could fix up some of the new homepages.  We've already seen some Gnu
> related package losses like gdal.  I think SWH adoption for packages may
> want to be moved from as packages are added to as packages are updated --
> just to have a regular, low overhead, but still slow move to SWH.
>
> What do you mean by "losses like gdal"?
>
> BTW, if the method of package origin is 'git-fetch' then "guix lint"
> should automatically queue the package to SWH.  And I guess that the
> Data Service or CI is linting, whatever the package is added or
> updated.
> The file 'sources.json' is updated every X minutes (or hours) and the
> SWH fetcher should be ready really soon.  And once this 'url-fetch'
> from SWH is on production, a lot of packages will move to SWH.
>
>
> Well, considering SWH, what is missing today IMHO on the Guix side is
> UI, e.g., display using "guix weather" if the package is in SWH or
> not, display a chart on the Data Service to represent which percentage
> is in SWH, maybe move the {package,source}-json-builder from the
> website engine to "guix publish", etc..  Help welcome. :-)
>
>
> All the best,
> simon
>

[-- Attachment #2: Type: text/html, Size: 2057 bytes --]

Re: Should guix track package aliases?

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> On Sun, 10 May 2020 at 12:08, Vincent Legoll <vincent.legoll@gmail.com> wrote:
>
>> Used googl often being used to approximate it, crudely but effectively.
>
> The big question is how to build such database.
> Wikidata?

There’s also the Common Platform Enumeration (CPE), the thing used to
refer to software in the CVE database.

Some of our packages have a ‘cpe-name’ property giving, well, their CPE
name so that ‘guix lint -c cve’ can do the right thing.

I wonder how <https://repology.org/> matches package names among distros
though.

Ludo’.