From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 30 08:03:39 2021 Received: (at 47479) by debbugs.gnu.org; 30 Mar 2021 12:03:39 +0000 Received: from localhost ([127.0.0.1]:50533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRD5v-0005bA-3s for submit@debbugs.gnu.org; Tue, 30 Mar 2021 08:03:39 -0400 Received: from flashner.co.il ([178.62.234.194]:38524) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRD5q-0005at-3U for 47479@debbugs.gnu.org; Tue, 30 Mar 2021 08:03:38 -0400 Received: from localhost (unknown [31.210.177.71]) by flashner.co.il (Postfix) with ESMTPSA id 6870E40088; Tue, 30 Mar 2021 12:03:27 +0000 (UTC) Date: Tue, 30 Mar 2021 15:02:44 +0300 From: Efraim Flashner To: Mark H Weaver Subject: Re: bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs Message-ID: References: <9beb8d6af78a517d53aaaa43179272b8953da78f.camel@telenet.be> <87lfa53bkj.fsf@netris.org> <8735wd2f77.fsf@netris.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AnAk6LbvaDZ56IY8" Content-Disposition: inline In-Reply-To: <8735wd2f77.fsf@netris.org> X-PGP-Key-ID: 0x41AAE7DCCA3D8351 X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc X-PGP-Fingerprint: A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47479 Cc: Maxime Devos , 47479@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --AnAk6LbvaDZ56IY8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 30, 2021 at 04:55:13AM -0400, Mark H Weaver wrote: > Hi Efraim, >=20 > Efraim Flashner writes: > > It is the case for inkscape@1.0.2 >=20 > 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. >=20 > 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. >=20 > > (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) | g= rep -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. >=20 > Good catch! >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 --=20 Efraim Flashner =D7=90=D7=A4=D7=A8=D7=99=D7=9D = =D7=A4=D7=9C=D7=A9=D7=A0=D7=A8 GPG key =3D A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted --AnAk6LbvaDZ56IY8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmBjE2EACgkQQarn3Mo9 g1FREQ/+OyADors/rDNPeO1H71+JIg325BJh6HC1CS/WBUP/nHBZDALy6mgXrgeq IShrIzyWt4hOsWHwj1imUQECvT9+ctYsnBXZE5OySROFArfXRMZF0OpPrBAagAcB XVY+5/i5SLUJaiLj50GaOIP80/mGGsHiLdGD3JiUC4NDMQMGRh2vRztLYZdXBzpM et99xNXfkRRiwS7v2vwUS+ttcU7W8LPGcscvI9A4w/Nl4gLR9ONYXElzEp9adfMB xeoPx0fiMecBxreoJAl/6ZYipbcnsaddnAIAqjLIwLR/r5/bzWGyV7t3XEQprGw8 6RL58ms58HQQJvQUkAmuKDnmGu8F8nP180P+5J0V7yR+i0WtowBLM4Hes0t+4j4L IZpk9WTLfa9RoV5QfK68wdSIEDibn1kCbfssdReyrecC5PDNsSLU3L3GBSZc80V2 rzCkOt/CJ2uX6R6JKVm2uHvaP2u4HH7zG8Di03KmGwvM66oUSfrQF5hcDaVQi/ft Vq3JzL8FFQpxfs+qGUYEfeEtSsL7lFYuk4MATOqs+7G1EwSufRFXd9HrYEonk4SP DHO5j3Ypk5rK1W6LZ9O7JElsparvbXDVxMHcemQe4FqFuRWMsD2dIvnYethK4o7M pvE20IGjasgCL8QWyaz+CjdYKQKwMZ6YUXa/yMuwNMoG54DEVgY= =DAN4 -----END PGP SIGNATURE----- --AnAk6LbvaDZ56IY8--