From: Tobias Geerinckx-Rice <me@tobias.gr>
To: Vincent Legoll <vincent.legoll@gmail.com>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: native or not
Date: Wed, 01 Apr 2020 21:23:27 +0200 [thread overview]
Message-ID: <87r1x7huxc.fsf@nckx> (raw)
In-Reply-To: <CAEwRq=qD6mRiTQhQorDOr6dh=ngi0BHuqUns3+o7gOKwwWRnDQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5437 bytes --]
Vincent,
Vincent Legoll 写道:
> On Tue, Mar 31, 2020 at 11:44 AM Tobias Geerinckx-Rice
> <me@tobias.gr> 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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2020-04-01 19:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-29 23:11 native or not Vincent Legoll
2020-03-30 6:57 ` Mathieu Othacehe
2020-03-30 21:25 ` Vincent Legoll
2020-03-30 22:07 ` Vincent Legoll
2020-03-31 7:45 ` Mathieu Othacehe
2020-03-31 8:02 ` Vincent Legoll
2020-03-31 9:17 ` Vincent Legoll
2020-03-31 17:54 ` Christopher Baines
2020-03-31 7:27 ` Mathieu Othacehe
2020-03-31 9:44 ` Tobias Geerinckx-Rice
2020-03-31 9:51 ` Vincent Legoll
2020-03-31 13:25 ` Marius Bakke
2020-03-31 22:01 ` Vincent Legoll
2020-03-31 22:04 ` [PATCH 1/6] gnu: cgit: Make some inputs native Vincent Legoll
2020-03-31 22:04 ` [PATCH 2/6] gnu: darktable: " Vincent Legoll
2020-04-01 13:58 ` Mathieu Othacehe
2020-04-01 14:15 ` Tobias Geerinckx-Rice
2020-03-31 22:04 ` [PATCH 3/6] gnu: graphviz: " Vincent Legoll
2020-03-31 22:04 ` [PATCH 4/6] gnu: iwd: " Vincent Legoll
2020-03-31 22:04 ` [PATCH 5/6] gnu: mailutils: " Vincent Legoll
2020-04-01 14:03 ` Mathieu Othacehe
2020-03-31 22:04 ` [PATCH 6/6] gnu: nethack: " Vincent Legoll
2020-04-01 14:06 ` Mathieu Othacehe
2020-03-31 23:07 ` [PATCH 1/6] gnu: cgit: " Tobias Geerinckx-Rice
2020-04-01 13:52 ` Mathieu Othacehe
2020-04-01 14:13 ` Tobias Geerinckx-Rice
2020-04-01 14:20 ` Mathieu Othacehe
2020-04-01 17:59 ` Vincent Legoll
2020-04-01 19:23 ` Tobias Geerinckx-Rice [this message]
2020-04-01 21:28 ` native or not Vincent Legoll
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r1x7huxc.fsf@nckx \
--to=me@tobias.gr \
--cc=guix-devel@gnu.org \
--cc=vincent.legoll@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.