Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Mark H Weaver <mhw@netris.org>]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> these are very good arguments, which I understand and share. But moving
> to another version is problematic even when there is no soname bump, as
> I wrote in my bug report https://issues.guix.gnu.org/47315; grafts with
> different version numbers lead to a command line behaviour that is not
> understandable:
>
> $ guix package -A imagemagick
> imagemagick	6.9.12-2g	out,doc	gnu/packages/imagemagick.scm:132:2
> imagemagick	6.9.11-48	out,doc	gnu/packages/imagemagick.scm:48:2
>
> $ guix build imagemagick@6.9.11
> guix build: error: imagemagick: package not found for version 6.9.11
>
> $ guix build imagemagick@6.9.11-48
> /gnu/store/c30y49vg735g6b4hh590zrc9fmvcsy0w-imagemagick-6.9.12-2g-doc
> /gnu/store/l3hr0fimip6v7vmkgxbqygsglxaxasy0-imagemagick-6.9.12-2g
>
> From a user's perspective, inkscape@6.9.11 is at the time there and not
> there; it is shown by "guix package", but then not accessible for install-
> ation, but silently "glossed over" in favour of a different version.
[...]
> Otherwise said, grafting to different versions breaks our semantic for
> designating packages, in which version numbers play an important role,
> and replaces it by a mess which even with the examples above I have a
> hard time understanding.

To my mind this suggests a bug, or at least suboptimal behavior, in
"guix package".  I don't think it's appropriate to set grafting policy
to work around it.

How about changing "guix package -A" and "guix package -s" to display
information about the package's replacement, if it has one?

Alternatively, those commands could somehow explicitly indicate that the
package has been grafted, and show the version number of the
replacement, in such a way that is less confusing to users.

What do you think?

     Regards,
       Mark