From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rutger Helling Subject: bug#38336: =?UTF-8?Q?=E2=80=98wine64-staging=E2=80=99?= is very expensive to build Date: Tue, 03 Dec 2019 09:17:56 +0100 Message-ID: References: <87r21z7bg8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_03b6e92efeca92f761221d3f04640a06" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:57606) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ic3Ok-00069b-Gq for bug-guix@gnu.org; Tue, 03 Dec 2019 03:19:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ic3Og-0004q9-Ux for bug-guix@gnu.org; Tue, 03 Dec 2019 03:19:06 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:33273) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ic3Og-0004p9-Q1 for bug-guix@gnu.org; Tue, 03 Dec 2019 03:19:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ic3Og-0002Re-Ib for bug-guix@gnu.org; Tue, 03 Dec 2019 03:19:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87r21z7bg8.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 38336@debbugs.gnu.org --=_03b6e92efeca92f761221d3f04640a06 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Hi Ludo, Sorry for the late reply. I'm not really active anymore in Guix development for various reasons. Wine needs a whole 32-bit dependency chain to be able to run both 32-bit and 64-bit code, since a Wine that can only run 64-bit code is considered useless. That is why the package is unfortunately so large. I don't think there's anything that can be done about that. A couple of binaries are also copied, not just JSON files. That is where the 32-bit dependencies come from. On 2019-11-23 00:12, Ludovic Courtès wrote: > Hello, > > I noticed that 'wine64-staging' is our most expensive package to build. > Initially I was surprised because it only has a couple of nodes more in > its object than 'wine-staging': > > --8<---------------cut here---------------start------------->8--- > ludo@ribbon ~/src/guix$ guix graph wine-staging |grep 'label = ' |wc -l > 509 > ludo@ribbon ~/src/guix$ guix graph wine64-staging |grep 'label = ' |wc -l > 511 > --8<---------------cut here---------------end--------------->8--- > > However, that single additional node leads to the duplication of the > whole derivation graph on x86_64-linux: > > --8<---------------cut here---------------start------------->8--- > ludo@ribbon ~/src/guix$ guix graph -t derivation wine-staging |grep 'label = ' |wc -l > 2738 > ludo@ribbon ~/src/guix$ guix graph -t derivation wine64-staging |grep 'label = ' |wc -l > 4598 > --8<---------------cut here---------------end--------------->8--- > > This is because 'wine-staging' has a hard-coded '#:system "i686-linux"', > whereas 'wine64-staging' is (unsurprisingly :-)) built on x86_64-linux. > > (The same problem happens with 'wine' vs. 'wine64'.) > > Likewise, 'guix size wine64' shows that every dependency appears twice > (one 32-bit, one 64-bit), and thus the total size is twice that of > 'wine'. > > Rutger, is there something that can be done to avoid this? Apparently > only JSON files are copied from 'wine-staging' into 'wine64-staging', > but maybe they refer to 32-bit shared libraries or something? > > Thanks, > Ludo'. --=_03b6e92efeca92f761221d3f04640a06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Ludo,

Sorry for the late reply. I'm not really active anymore in Guix developm= ent for various reasons.

Wine needs a whole 32-bit dependency chain to be able to run both 32-bit= and 64-bit code, since a Wine that can only run 64-bit code is considered = useless. That is why the package is unfortunately so large. I don't think t= here's anything that can be done about that.

A couple of binaries are also copied, not just JSON files. That is where= the 32-bit dependencies come from.

On 2019-11-23 00:12, Ludovic Courtès wrote:

= Hello,

I noticed that ‘wine64-staging’ is our most e= xpensive package to build.
Initially I was surprised because it only h= as a couple of nodes more in
its <package> object than ‘wi= ne-staging’:

--8<---------------cut here---------------= start------------->8---
ludo@ribbon ~/src/guix$ guix graph wine-sta= ging |grep 'label =3D ' |wc -l
509
ludo@ribbon ~/src/guix$ guix g= raph wine64-staging |grep 'label =3D ' |wc -l
511
--8<--------= -------cut here---------------end--------------->8---

However= , that single additional node leads to the duplication of the
whole de= rivation graph on x86_64-linux:

--8<---------------cut here--= -------------start------------->8---
ludo@ribbon ~/src/guix$ guix g= raph -t derivation wine-staging |grep 'label =3D ' |wc -l
2738
lu= do@ribbon ~/src/guix$ guix graph -t derivation wine64-staging |grep 'label = =3D ' |wc -l
4598
--8<---------------cut here---------------en= d--------------->8---

This is because ‘wine-staging&rsq= uo; has a hard-coded ‘#:system "i686-linux"’,
whereas &lsq= uo;wine64-staging’ is (unsurprisingly :-)) built on x86_64-linux.

(The same problem happens with ‘wine’ vs. ‘wine64= ’.)

Likewise, ‘guix size wine64’ shows that ev= ery dependency appears twice
(one 32-bit, one 64-bit), and thus the to= tal size is twice that of
‘wine’.

Rutger, is th= ere something that can be done to avoid this?  Apparently
only JS= ON files are copied from ‘wine-staging’ into ‘wine64-stag= ing’,
but maybe they refer to 32-bit shared libraries or somethi= ng?

Thanks,
Ludo’.



--=_03b6e92efeca92f761221d3f04640a06--