* duplicate package names in channels @ 2022-09-30 19:48 Fulbert 2022-09-30 20:01 ` Julien Lepiller 0 siblings, 1 reply; 3+ messages in thread From: Fulbert @ 2022-09-30 19:48 UTC (permalink / raw) To: help-guix 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: duplicate package names in channels 2022-09-30 19:48 duplicate package names in channels Fulbert @ 2022-09-30 20:01 ` Julien Lepiller 2022-09-30 20:10 ` Fulbert 0 siblings, 1 reply; 3+ messages in thread From: Julien Lepiller @ 2022-09-30 20:01 UTC (permalink / raw) To: help-guix, Fulbert 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 > ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: duplicate package names in channels 2022-09-30 20:01 ` Julien Lepiller @ 2022-09-30 20:10 ` Fulbert 0 siblings, 0 replies; 3+ messages in thread From: Fulbert @ 2022-09-30 20:10 UTC (permalink / raw) To: help-guix 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 > > ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-09-30 20:32 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-09-30 19:48 duplicate package names in channels Fulbert 2022-09-30 20:01 ` Julien Lepiller 2022-09-30 20:10 ` Fulbert
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.