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

[Efraim Flashner <efraim@flashner.co.il>]

[-- Attachment #1: Type: text/plain, Size: 3662 bytes --]

On Tue, Mar 30, 2021 at 04:55:13AM -0400, Mark H Weaver wrote:
> 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?

In the past we've kept the most up-to-date version as the 'main version'
and given the version suffix to the older version(s). Except for when
they all get version suffixes and then a separate (define rust
rust-1.45) package added.

> 
> > (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.

I ran into this also with the cargo-build-system. I only wanted to
propagate regular inputs, not native inputs. It's probably worth
figuring out how to fix some of it on core-updates.

> 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?

We can always try to make it better. In the mean time perhaps we can try
changing the way some of the wrappers work to only accept regular
inputs, or possibly to specify exactly which inputs to iterate over and
to use in the wrap phases.

>     Regards,
>       Mark

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]