Vincent, Vincent Legoll 写道： > On Tue, Mar 31, 2020 at 11:44 AM Tobias Geerinckx-Rice > wrote: >> There's some deeper confusion here: why do you expect the size >> to >> change, at all? > > Because I've been told so... Hm. I don't think it's correct. Perhaps this was in the context of one specific case where making something native had this pleasant side effect? It's certainly not the reason native-inputs and inputs exist. >> Making ‘groff’ native was the right thing to do (and please, >> 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 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 talking about closure myself, so that doesn't change my points above. > And if I've understood that may be visible for ISO, VM, > container > image sizes. > > Am I mistaken ? You're correct that the size of an ISO (or VM, container, …) is nothing more than the ‘final closure’ over all the store items that it contains. > Still learning... Of course! This is something that confuses *many* people initially, until it finally clicks. Below this mail, I'm attaching a draft of the response I'd written to your first message in this thread. I abandoned it due to time constraints. It's… rough, and I've explained this much better on IRC at least once, but maybe it can help. Kind regards, T G-R ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Vincent Legoll 写道： > 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 - ‘inputs’ is just a fancy word for ‘run-time dependency’, and - ‘native-inputs’ is just an obscure way to say ‘build-time dependency’. It's very important that you understand that neither of those is 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 ‘/gnu/store/-foo’ appear anywhere in ‘/gnu/store/-bar’? If so, then foo is a dependency of bar because bar ‘refers’ to foo. That's it. 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 ‘/gnu/store/…’ strings it finds were once native, and which weren't. Nativeness This is a vast oversimplification (no mention of .drvs and of course Guix can't be simply chopped in half Solomon-stylee), but it's been helpful before. I've also ignored propagated-inputs, which is 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) fix cross-compilation. You can always try that yourself with $ guix build --target=mips64el-linux-gnu sudo Guix will build/install a cross-toolchain the first time, which will take a while, but after that you'll be building just regular packages at roughly the same speed. When not cross-compiling, there's no difference at all: - With groff as a regular input: $ guix build sudo … environment variable `PATH' set to `…:/gnu/store/hhwzz…-groff-1.22.4/bin:…' environment variable `LIBRARY_PATH' set to `…:/gnu/store/hhwzz…-groff-1.22.4/lib:…' … - 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 … environment variable `PATH' set to `…:/gnu/store/hhwzz…-groff-1.22.4/bin:…' environment variable `LIBRARY_PATH' set to `…:/gnu/store/hhwzz…-groff-1.22.4/lib:…' … Nope. That's right: when not cross-compiling, all your precious native-vs.-not distinctions are tossed in the bin before the build has even started. > Are those changes useful to do on their own ? Absolutely! Making groff native here is the right thing to do. You just got distracted by something as irrelevant as size ;-) Kind regards, T G-R [0]: This is something we inherited from Nix.