Re: Rebuilding a package after removing a build step

[Konrad Hinsen <konrad.hinsen@fastmail.net>]

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.