all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Efraim Flashner <efraim@flashner.co.il>
Cc: 47479@debbugs.gnu.org
Subject: bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs
Date: Tue, 30 Mar 2021 04:55:13 -0400	[thread overview]
Message-ID: <8735wd2f77.fsf@netris.org> (raw)
In-Reply-To: <YGLRBGytQfTcioO4@3900XT>

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




  reply	other threads:[~2021-03-30  8:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29 16:33 bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs Maxime Devos
2021-03-29 21:16 ` Mark H Weaver
2021-03-30  7:19   ` Efraim Flashner
2021-03-30  8:55     ` Mark H Weaver [this message]
2021-03-30 12:02       ` Efraim Flashner
2021-03-30 15:38       ` Leo Famulari
2021-03-30 22:48         ` Mark H Weaver
2021-03-31  5:30           ` Leo Famulari
2021-03-31  7:52             ` Mark H Weaver
2021-04-06 14:15         ` Maxim Cournoyer
2024-01-22  1:15           ` Maxim Cournoyer
     [not found] ` <handler.47479.D47479.170588611628229.notifdone@debbugs.gnu.org>
2024-01-22  4:07   ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735wd2f77.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=47479@debbugs.gnu.org \
    --cc=efraim@flashner.co.il \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.