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 <fulb...@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 >