From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tobias Geerinckx-Rice Subject: Re: native or not Date: Wed, 01 Apr 2020 21:23:27 +0200 Message-ID: <87r1x7huxc.fsf@nckx> References: <87a73ypbyb.fsf@gmail.com> <87h7y4kgdq.fsf@nckx> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:34066) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJixZ-0005fk-5K for guix-devel@gnu.org; Wed, 01 Apr 2020 15:23:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jJixX-000667-GD for guix-devel@gnu.org; Wed, 01 Apr 2020 15:23:32 -0400 Received: from tobias.gr ([2a02:c205:2020:6054::1]:60874) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jJixX-00064W-1X for guix-devel@gnu.org; Wed, 01 Apr 2020 15:23:31 -0400 In-reply-to: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Vincent Legoll Cc: guix-devel --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Vincent, Vincent Legoll =E5=86=99=E9=81=93=EF=BC=9A > On Tue, Mar 31, 2020 at 11:44 AM Tobias Geerinckx-Rice=20 > wrote: >> There's some deeper confusion here: why do you expect the size=20 >> to >> change, at all? > > Because I've been told so... Hm. I don't think it's correct. Perhaps this was in the context=20 of one specific case where making something native had this=20 pleasant side effect? It's certainly not the reason native-inputs and inputs exist. >> Making =E2=80=98groff=E2=80=99 native was the right thing to do (and ple= ase,=20 >> keep >> fixing bugs like this! :-) but it has nothing to do with making >> packages smaller. > > Never will ? If not never, as a happy side effect at best. Doing anything for its side effect while being unaware of their=20 potentially significant main effects is a recipe for ruin. > I'm not expecting package size to shrink, but package closure > (is that the right word) size to sometimes shrink. So yes, I think you're using the right word. I was certainly=20 talking about closure myself, so that doesn't change my points=20 above. > And if I've understood that may be visible for ISO, VM,=20 > container > image sizes. > > Am I mistaken ? You're correct that the size of an ISO (or VM, container, =E2=80=A6) is=20 nothing more than the =E2=80=98final closure=E2=80=99 over all the store it= ems=20 that it contains. > Still learning... Of course! This is something that confuses *many* people=20 initially, until it finally clicks. Below this mail, I'm attaching a draft of the response I'd written=20 to your first message in this thread. I abandoned it due to time=20 constraints. It's=E2=80=A6 rough, and I've explained this much better on=20 IRC at least once, but maybe it can help. Kind regards, T G-R ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Vincent Legoll =E5=86=99=E9=81=93=EF=BC=9A > And looking at the guix lint page, I saw the "should > probably be native input" warnings, and gave it a > try on sudo, naively thinking it would benefit > something (maybe a container or vm image size). The linter doesn't mention size at all, so there's a hidden (but common) assumption above: that =2D =E2=80=98inputs=E2=80=99 is just a fancy word for =E2=80=98run-time dep= endency=E2=80=99, and =2D =E2=80=98native-inputs=E2=80=99 is just an obscure way to say =E2=80=98= build-time=20 dependency=E2=80=99. It's very important that you understand that neither of those is=20 true. It might help to think of Guix as two completely separate things: 1. a functional package builder that takes a package recipe and its various inputs (mainly source & {native-,}inputs), builds it, and saves the output to /gnu/store/-package. While it's true that build-time-only dependencies are often native-inputs, and run-time dependencies should probably be regular inputs, the two aren't equivalent 2. a functional package manager that only deals with the items (build artefacts) that it finds in /gnu/store. It's important to note that this part does *not* deal with package recipes at all! The notion of a run-time dependency in Guix is simple and brilliant[0]: does the string =E2=80=98/gnu/store/-foo=E2=80=99 ap= pear anywhere in =E2=80=98/gnu/store/-bar=E2=80=99? If so, then foo is= a dependency of bar because bar =E2=80=98refers=E2=80=99 to foo. That's i= t. This side of Guix's personality doesn't care about package recipes *at all*. Which is good, since it needs to deal with store items whose package recipes have long vanished. Therefore, it can't know or care which =E2=80=98/gnu/store/=E2=80=A6=E2= =80=99 strings it finds were once native, and which weren't. Nativeness This is a vast oversimplification (no mention of .drvs and of=20 course Guix can't be simply chopped in half Solomon-stylee), but it's=20 been helpful before. I've also ignored propagated-inputs, which is=20 fine. > Is there a way to see any benefit from these changes > (without building a vm or container image each time) ? The benefit is that, if your changes are correct, it will (help)=20 fix cross-compilation. You can always try that yourself with $ guix build --target=3Dmips64el-linux-gnu sudo Guix will build/install a cross-toolchain the first time, which=20 will take a while, but after that you'll be building just regular=20 packages at roughly the same speed. When not cross-compiling, there's no difference at all: =2D With groff as a regular input: $ guix build sudo =E2=80=A6 environment variable `PATH' set to=20 `=E2=80=A6:/gnu/store/hhwzz=E2=80=A6-groff-1.22.4/bin:=E2=80=A6' environment variable `LIBRARY_PATH' set to=20 `=E2=80=A6:/gnu/store/hhwzz=E2=80=A6-groff-1.22.4/lib:=E2=80=A6' =E2=80=A6 =2D Now let's make groff as a native-input: surely this will have an effect on, say, which libraries we're allowed to link against? $ guix build sudo =E2=80=A6 environment variable `PATH' set to=20 `=E2=80=A6:/gnu/store/hhwzz=E2=80=A6-groff-1.22.4/bin:=E2=80=A6' environment variable `LIBRARY_PATH' set to=20 `=E2=80=A6:/gnu/store/hhwzz=E2=80=A6-groff-1.22.4/lib:=E2=80=A6' =E2=80=A6 Nope. That's right: when not cross-compiling, all your precious=20 native-vs.-not distinctions are tossed in the bin before the build=20 has even started. > Are those changes useful to do on their own ? Absolutely! Making groff native here is the right thing to do.=20 You just got distracted by something as irrelevant as size ;-) Kind regards, T G-R [0]: This is something we inherited from Nix. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl6E6i8ACgkQ2Imw8BjF STz2xQ/8DH8qfECiWyL407bAfDJWoJ3JLsMVpsYLRQe0sf5ssAyuhNlwf32llDvw Vv0LV7blo0vkZDNwKPqWP2gWqIAjeiUIZS5DbBz3gKsSxjJudDLAoxhN6a4w7+VN haWDCJggldAPiKLRKdn0JPgWDNKIKLHeInvX7fAUHsqE4ZtGbqB2b7p37sMTOZEc +Vts4aZfoZOyN+Q9DztOXzFKS8iDy6Dt9VnE6OJ2i8SFZr36/tpeea+rEtYYTsHr GvJhmtdJJ41Z1avDZ8i0lu4Ok0p2f8HxiyNRQD8I13dQJFUvQxuqg19FBxGWXvTE H7f6WehhkHRKIRwtVLdl6iI1HOShv6NnjNHGwxXmdr6ZHg7y9UhHDjwoe2NxbxZG K251hxdGtSj2Lmny0hObtJxlaFstjOpD63iIJd81E3s3eoOzTRlOfGR/WAARMd6z x+7/NTg8SEbCO5jagoTN2+HabPAbvqpwvPrAAWvhtRfa7ck61MNJgfrpTOlEOqG0 2LeFByeT1oC8tFyuon3g84/gI8cohe3/K1C6vtcF3SxltYVc4cB/dmxFAX4eR3Iz VPLrFrbvka1Hro3S++mmWxA+nvG4rcfeDcQ4UIq4H2OkF4Dy9tppTstJEZPmRxsE efK8Zqqzygr41zIyiWyyCN3+glzrX/NG52K9ad8v6XK5+24fP9E= =QvQh -----END PGP SIGNATURE----- --=-=-=--