[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Grandfathering store paths considered harmful
From: |
Ludovic Courtès |
Subject: |
Re: Grandfathering store paths considered harmful |
Date: |
Thu, 19 Jan 2023 15:28:30 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi Liliana,
Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
> For context, emacs uses a hash digest to more or less uniquely
> fingerprint the version (much like guix does), so natively compiling
> things with emacs-minimal won't speed up your packages when using emacs
> or emacs-next and is thus next to pointless.
If emacs-minimal lacks JIT support anyway, there’s nothing it can
compile? Or am I missing something?
(It’s called “JIT” but we keep talking about things that need to be done
ahead-of-time, this is confusing. :-))
> I witnessed the same type of bug in wpewebkit, which pulls in the much
> larger webkitgtk, probably because the former uses #$output rather than
> (assoc-ref outputs "out") in one of its phases – see the attached patch
> for my proposed fix.
I believe the attached patch has no effect. #$output expands to (getenv
"out"), where "out" is an automatic environment variable of the
derivation.
> If my hunch is correct, this has some further reaching implications.
> It means, that uses of #$output and #$(this-package-input) – which we
> want to promote instead of labels – draw in additional inputs when
> combined with inheritance, which in the context of this thread I hope
> we can all agree is not good.
‘this-package-input’ is different from #$output because it’s a purely
host-side feature. It refers to inputs of the package in which it
appears; thus, if you define a package B that inherits from A, and the
‘arguments’ of A contain (this-package-input "whatever"), that is fine:
B’s ‘arguments’ will refer to its own “whatever”¹.
Now, independent of that, it’s easy to make mistakes when using
inheritance heavily. The only good solution to that IMO is to avoid
factorizing too much. That is, in some cases, it may be more robust to
be explicit in inherited packages—e.g., explicitly providing ‘inputs’
and ‘arguments’ fields—than to inherit all the fields from some distant
parent package.
I hope that makes sense!
Ludo’.
¹ See the bit about self-referential records in
<https://guix.gnu.org/en/blog/2021/the-big-change/>.
- Re: Packages grow, no longer fit on a 💾, (continued)
Re: Packages grow, no longer fit on a 💾, Akib Azmain Turja, 2023/01/15
Re: Packages grow, no longer fit on a 💾, pelzflorian (Florian Pelz), 2023/01/15
- Re: Packages grow, no longer fit on a 💾, Ludovic Courtès, 2023/01/17
- Re: Packages grow, no longer fit on a 💾, zimoun, 2023/01/17
- Re: Packages grow, no longer fit on a 💾, zimoun, 2023/01/17
- Grandfathering store paths considered harmful (was: Packages grow, no longer fit on a 💾), Liliana Marie Prikler, 2023/01/18
- Re: Grandfathering store paths considered harmful,
Ludovic Courtès <=
- Re: Grandfathering store paths considered harmful, Liliana Marie Prikler, 2023/01/19
Re: Packages grow, no longer fit on a 💾, Ludovic Courtès, 2023/01/19
Re: Packages grow, no longer fit on a 💾, Simon Tournier, 2023/01/20
Re: Packages grow, no longer fit on a 💾, Maxim Cournoyer, 2023/01/20
Re: Packages grow, no longer fit on a 💾, kiasoc5, 2023/01/17
Re: Packages grow, no longer fit on a 💾, indieterminacy, 2023/01/18
Re: Packages grow, no longer fit on a 💾, Ludovic Courtès, 2023/01/19
Re: Packages grow, no longer fit on a 💾, Simon Tournier, 2023/01/20
Re: Packages grow, no longer fit on a 💾, Efraim Flashner, 2023/01/17