bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs

[Mark H Weaver]

Hi Efraim,

Efraim Flashner <efraim@flashner.co.il> writes:
> It is the case for inkscape@1.0.2

I see now that I'm using an older version, although I would have
preferred the newer one.  I refer to the variable name 'inkscape' from
my manifest file, and I expected that to point to the latest stable
version.  However, it seems that one must use the 'inkscape-1.0'
variable to get the latest stable version.  That's seems suboptimal.

I wonder if the 'inkscape' variable should be renamed 'inkscape/stable'
(for use in packages such as 'dblatex/stable'), and then 'inkscape'
could be repurposed to point to the latest stable version.  Thoughts?

> (ins)efraim@3900XT ~$ guix package -A inkscape
> inkscape        1.0.2   out     gnu/packages/inkscape.scm:121:2
> inkscape        0.92.4  out     gnu/packages/inkscape.scm:56:2
> (ins)efraim@3900XT ~$ guix gc --references $(guix build inkscape@1) | grep -i 
> imagemagick
> /gnu/store/y4rym48vihmh3jk9qnll0zqfnxzi9n6v-imagemagick-6.9.12-4
>
> I believe it comes from the glib-or-gtk-wrap phase where it wraps the
> XDG_DATA_DIRS and likely grabs more than it needs.

Good catch!

So, for now, we shouldn't use 'imagemagick/stable' in 'inkscape', even
though it's in 'native-inputs'.  This shows that we'll have to be very
careful about this, at least until we have better tooling to catch these
problems automatically.

I think the fundamental problem here is that the build-side code cannot
distinguish between 'inputs' and 'native-inputs' unless you are
cross-compiling.  When compiling natively, the 'inputs' keyword argument
passed to the build phases includes the packages listed in the
'native-inputs' package field, and the 'native-inputs' keyword argument
is not passed at all.

This is why we must write (or native-inputs inputs) in so many places:
because to find the location of a package listed in the 'native-inputs'
package field from within build-side code, you must look in one of two
places depending on whether you're cross-compiling.  If you're
cross-compiling you must look in 'native-inputs'.  When compiling
natively, that argument doesn't even exist, and you must look in the
'inputs' keyword argument instead.

I don't know why it was done this way.  It seems to me an error-prone
design, but at this point it would be hard to change it.

Now we see another disadvantage.  The 'glib-or-gtk-wrap' phase should be
iterating over the 'inputs' but not the 'native-inputs'.  It's not
obvious how to fix this given the current design.

What do you think?

    Regards,
      Mark