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

["Ludovic Courtès" <ludo@gnu.org>]

Hi Mark,

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

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> pkill9 <pkill9@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’.