Grandfathering store paths considered harmful (was: Packages grow, no longer fit on a 💾)

[Liliana Marie Prikler]

Am Mittwoch, dem 18.01.2023 um 00:49 +0100 schrieb zimoun:
> 
> On Wed, 18 Jan 2023 at 00:05, zimoun <zimon.toutoune@gmail.com>
> wrote:
> 
> > For emacs-minimal, if considered to only bytecompile (.elc) and not
> > native compile, this libgccgit seems unexpected, indeed.  Well, is
> > native compilation disabled for emacs-minimal?  I guess not. :-)
> 
> The package emacs-minimal is only for bytecompiling and configured
> without native compilation, IIUC.  Thus the reference to libgccgit
> appears unexpected, then tackled by Josselin and fixed by Liliana in
> #60831 [1].
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.

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.  Note, I'm saying probably, because the build
still runs, but the fact that it started without first running the
webkitgtk build gives me hope that my assumption is correct.  Still
takes ages and huge amounts of RAM tho.

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.

So, any ideas on how to tackle this? :)

0001-gnu-webkitgtk-Resolve-outputs-at-build-time.patch
Description: Text Data