duplicate package names in channels

duplicate package names in channels

[Fulbert]

Hello !

I'm not sure if guix supports similar package names [and version number]
provided in more than one “active” channels (declared in the list of
'~/.config/guix/channels.scm, including %default-channels)…
a) if 2 packages share their name, version and package definition,
yielding the exact same result, thus sharing the same hash and
/gnu/store/ storage-space (one “recognizing” the other hash, avoiding
redondant build or conflict ?) ;
b) if 2 packages share their name but not the version, thus yielding
distinct hashes, could guix automatically choose the highest available
version, similar to what guix does when it provides multiple versions of
the same name package in the main 'guix channel ? ;
c) if 2 packages share their name and version but do not yield the same
result/hash (… that's the only case where I'm abble to see a conflict).

As far as i understand, (c) would be problematic, thus (a) would require
a pre-build of both and conflict management, which is unlikely(?) and
consequently, (b) would require a user to remove manually a package in
the additionnal channel before it leads to (a).

So, my guess work gives NO, NO and NO, but I would be gratefull if
someone could confirm, eventually with a pointer to the manual or other
doc. (I am unable to check that for myself in the sources with any
degree of comprehension, let alone certainty ^^)

Thanks for guix and best regards,
Fulbert

Re: duplicate package names in channels

[Julien Lepiller]

Build results are kind of content-addressed, so when two separate packages yield the same hash, it means they are the same package, and no rebuild is necessary.

For the other two questions, it depends from which perspective you're looking at. From the code point of view, there are no difference between packages from guix and a channel. When two packages yield a different hash, they are considered different, so both are built if needed. Also, the code has direct reference to a given package, you can't reference "whatever provides gcc", you have to reference a specific gcc package, either from a channel or from the main guix.

So from the code point of view, two packages may have the same name and even version, and this is never ambiguous. Because packages are stored as Guile variables and when you specify a variable name it can only reference one value.

From the user point of view, esp. the CLI, you seem to have noticed that guix will chose the highest version number when you ask for a package without an explicit version number. This does not change whether packages come from a channel or from guix.

When two packages have the same name and version, guix will arbitrarily (but reproducibly :p) chose one or the other.

HTH!

Le 30 septembre 2022 21:48:31 GMT+02:00, Fulbert <fulbert@bluewin.ch> a écrit :
>Hello !
>
>I'm not sure if guix supports similar package names [and version number]
>provided in more than one “active” channels (declared in the list of
>'~/.config/guix/channels.scm, including %default-channels)…
>a) if 2 packages share their name, version and package definition,
>yielding the exact same result, thus sharing the same hash and
>/gnu/store/ storage-space (one “recognizing” the other hash, avoiding
>redondant build or conflict ?) ;
>b) if 2 packages share their name but not the version, thus yielding
>distinct hashes, could guix automatically choose the highest available
>version, similar to what guix does when it provides multiple versions of
>the same name package in the main 'guix channel ? ;
>c) if 2 packages share their name and version but do not yield the same
>result/hash (… that's the only case where I'm abble to see a conflict).
>
>As far as i understand, (c) would be problematic, thus (a) would require
>a pre-build of both and conflict management, which is unlikely(?) and
>consequently, (b) would require a user to remove manually a package in
>the additionnal channel before it leads to (a).
>
>So, my guess work gives NO, NO and NO, but I would be gratefull if
>someone could confirm, eventually with a pointer to the manual or other
>doc. (I am unable to check that for myself in the sources with any
>degree of comprehension, let alone certainty ^^)
>
>Thanks for guix and best regards,
>Fulbert
>

Re: duplicate package names in channels

[Fulbert]

It does help 6/5 !

Thank you for your time and explanation…  not to mention the swiftness !

Best regards,
Fulbert

Le Fri, Sep 30, 2022 at 10:01:39PM +0200, Julien Lepiller a écrit :
> Build results are kind of content-addressed, so when two separate packages yield the same hash, it means they are the same package, and no rebuild is necessary.
> 
> For the other two questions, it depends from which perspective you're looking at. From the code point of view, there are no difference between packages from guix and a channel. When two packages yield a different hash, they are considered different, so both are built if needed. Also, the code has direct reference to a given package, you can't reference "whatever provides gcc", you have to reference a specific gcc package, either from a channel or from the main guix.
> 
> So from the code point of view, two packages may have the same name and even version, and this is never ambiguous. Because packages are stored as Guile variables and when you specify a variable name it can only reference one value.
> 
> From the user point of view, esp. the CLI, you seem to have noticed that guix will chose the highest version number when you ask for a package without an explicit version number. This does not change whether packages come from a channel or from guix.
> 
> When two packages have the same name and version, guix will arbitrarily (but reproducibly :p) chose one or the other.
> 
> HTH!
> 
> Le 30 septembre 2022 21:48:31 GMT+02:00, Fulbert <fulbert@bluewin.ch> a écrit :
> >Hello !
> >
> >I'm not sure if guix supports similar package names [and version number]
> >provided in more than one “active” channels (declared in the list of
> >'~/.config/guix/channels.scm, including %default-channels)…
> >a) if 2 packages share their name, version and package definition,
> >yielding the exact same result, thus sharing the same hash and
> >/gnu/store/ storage-space (one “recognizing” the other hash, avoiding
> >redondant build or conflict ?) ;
> >b) if 2 packages share their name but not the version, thus yielding
> >distinct hashes, could guix automatically choose the highest available
> >version, similar to what guix does when it provides multiple versions of
> >the same name package in the main 'guix channel ? ;
> >c) if 2 packages share their name and version but do not yield the same
> >result/hash (… that's the only case where I'm abble to see a conflict).
> >
> >As far as i understand, (c) would be problematic, thus (a) would require
> >a pre-build of both and conflict management, which is unlikely(?) and
> >consequently, (b) would require a user to remove manually a package in
> >the additionnal channel before it leads to (a).
> >
> >So, my guess work gives NO, NO and NO, but I would be gratefull if
> >someone could confirm, eventually with a pointer to the manual or other
> >doc. (I am unable to check that for myself in the sources with any
> >degree of comprehension, let alone certainty ^^)
> >
> >Thanks for guix and best regards,
> >Fulbert
> >