GNU bug report logs - #43984
`--with-graft=...` doesn't work with packages of different length name/version

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: pkill9 <pkill9 <at> runbox.com>, 43984 <at> debbugs.gnu.org
Subject: bug#43984: `--with-graft=...` doesn't work with packages of different length name/version
Date: Wed, 21 Oct 2020 10:45:19 +0200

Hi Mark,

Mark H Weaver <mhw <at> netris.org> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> pkill9 <pkill9 <at> runbox.com> skribis:
>>
>>>> All I’m saying is that nothing can be done when the new name is longer
>>>> than the old one: we just cannot graft.
>>>
>>> If a symlink is used though, it wouldn't matter if the new name is
>>> longer, the symlink would point to the new package, and the name of the
>>> symlink would match the length of the old package.
>>
>> But who would refer to that symlink?  The thing on which the graft is
>> applied can only refer to the store item that has the right length.
>
> If I understand correctly, pkill9's idea is that intermediate symlink(s)
> (presumably one for each output of the replacement package) would have
> the same length as the original store item, but could point to a
> replacement store item of greater length.
>
> For example, whereas now we must *build* our replacement libx11 with
> munged version number "1.6.A", under pkill9's approach we could instead
> build it with normal version number "1.6.10", and only the intermediate
> symlink(s) would have their names munged to fit within the original
> length limit.  The grafting process would then rewrite the original
> store references to point to the symlink(s).
>
> An advantage to this approach is that the replacement packages would no
> longer need to have their version numbers munged, which would be more
> aesthetically pleasing and perhaps less confusing for users.  The lack
> of munging might also make the replacement package more attractive for
> _direct_ usage as a package input by non-core packages that need the
> newer version of the replaced package for other reasons.

Oh that makes sense, thanks for explaining.

It could be useful to implement this; it would make ‘--with-graft’ more
generally applicable, which was pkill9’s initial goal.

Package replacements often have the same length as the original, so for
those we wouldn’t change anything; it would make a difference in other
cases though.

> Disadvantages include potentially slower file system lookups in the
> replaced packages, and added complexity in Guix.

Yes, though that’s probably reasonable.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.