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

[Mark H Weaver]

Hi Ludovic,

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.

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

I don't have an opinion on this, but I wanted to at least try to clarify
the idea that pkill9 is proposing.

     Regards,
       Mark