Re: native or not

[Tobias Geerinckx-Rice]

Vincent,

Vincent Legoll 写道：
> On Tue, Mar 31, 2020 at 11:44 AM Tobias Geerinckx-Rice 
> <address@hidden> 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/<hash>-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/<hash>-foo’ appear
  anywhere in ‘/gnu/store/<hash>-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.

signature.asc
Description: PGP signature