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
> >