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

Previous Next

Full log

Message #29 received at 47479 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Leo Famulari <leo <at> famulari.name>
Cc: Efraim Flashner <efraim <at> flashner.co.il>, 47479 <at> debbugs.gnu.org
Subject: Re: bug#47479: inkscape retains a reference to imagemagick, even
 though it is in native-inputs
Date: Wed, 31 Mar 2021 03:52:22 -0400

Hi Leo,

Leo Famulari <leo <at> famulari.name> writes:
> I didn't realize / remember that Inkscape was used that deep in the
> package graph. I agree, we should delay this change, at least until a
> rebuild cycle.

The removal of inkscape <at> 0.92.4 should certainly be delayed, but I see no
reason why we couldn't immediately, on 'master', rename the variable
'inkscape' to 'inkscape/stable', and 'inkscape-1.0' to 'inkscape', with
'inkscape-1.0' made an alias to 'inkscape', if we can agree on it.
Do you see a reason to delay those changes?

> I do think it's suboptimal that an end-user application like Inkscape
> is depended on by so many packages...

Indeed, it's not good.  In fact, the question just occurred to me:

 "How is it that Inkscape, which clearly depends on Gtk+, can also be a
  dependency of Gtk+, via the path gtk+ -> at-spi2-atk -> at-spi2-core
  -> gtk-doc -> dblatex -> inkscape <at> 0.92.4?"

It turns out that the only reason there's no cycle here is because:

(1) the older inkscape <at> 0.92.4 uses gtk+-2 (not 3), and
(2) none of the dependencies of gtk+-2 use gtk-doc.

Both of these are likely suboptimal, but we will apparently be blocked
from fixing these issues while Inkscape is needed to build our core
graphics stack.

In my opinion, the best way to fix this is to split off documentation
generation for selected core libraries into separate packages.
Generating documentation often requires higher-level components, and yet
we should also generate documentation for our core libraries.  This
naturally leads to cycles unless the documentation is split off.  We
should use the core libraries (without docs) to build the documentation
generators, and then from there build the documentation for the core
libraries.

What do you think?

Thanks for the discussion,

      Mark

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.