Hi Ludo, >> Unfortunately, when there are several packages with identical name and >> version number in two channels, Guix silently chooses one of them. >> It would probably be more useful to emit a warning. > > I believe that’s already the case.
We already had some discussion, the conclusion being that there are indeed tests for equal and for "higher" version, but that these tests do not always correspond to the intention of "choosing the newest version". In particular, Guix uses version *strings* rather than version *numbers*, with alphabetical ordering for the non-numerical parts of these strings. In the common case of version strings containing git commit hashes, alphabetical order does not correspond to "newest version". So you can consider yourself safe when working on the most recent commit of a package, and yet end up building a older but alphabetically higher version from another channel. Andreas pointed out that this is the reason for adding a manually curated revision number before such hashes. But there is no coordination mechanism for such revision number across channels. Vagrant suggested deriving a version number from the commit history using "git describe". That sounds like a good solution, but it's not used in Guix as far as I can tell. Cheers, Konrad.
