* bug#43984: `--with-graft=...` doesn't work with packages of different length name/version
@ 2020-10-14 0:55 pkill9
2020-10-15 7:50 ` Ludovic Courtès
0 siblings, 1 reply; 8+ messages in thread
From: pkill9 @ 2020-10-14 0:55 UTC (permalink / raw)
To: 43984
As expected, if you attempt to graft a package's dependency, and it's
name + version is different length to the original dependency, then it
will fail to graft.
Maybe if the length/version is different, then a symlink could be
created in the store pointing to the new dependency, with a
name/version that matches the length of the original dependency's store
name? Perhaps this new name/version could be something like
/gnu/store/...-original-dependency-name-gggggg, where 'g..' matches the
length of the version of the original dependency. The many 'g's would
make it clear that it is a graft. Then if someone looks in the store,
they would see it's a symlink too.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#43984: `--with-graft=...` doesn't work with packages of different length name/version
2020-10-14 0:55 bug#43984: `--with-graft=...` doesn't work with packages of different length name/version pkill9
@ 2020-10-15 7:50 ` Ludovic Courtès
2020-10-15 18:50 ` pkill9
0 siblings, 1 reply; 8+ messages in thread
From: Ludovic Courtès @ 2020-10-15 7:50 UTC (permalink / raw)
To: pkill9; +Cc: 43984
Hi,
pkill9 <pkill9@runbox.com> skribis:
> As expected, if you attempt to graft a package's dependency, and it's
> name + version is different length to the original dependency, then it
> will fail to graft.
Yes, that’s expected, but perhaps the manual could state it more
prominently?
> Maybe if the length/version is different, then a symlink could be
> created in the store pointing to the new dependency, with a
> name/version that matches the length of the original dependency's store
> name? Perhaps this new name/version could be something like
> /gnu/store/...-original-dependency-name-gggggg, where 'g..' matches the
> length of the version of the original dependency. The many 'g's would
> make it clear that it is a graft. Then if someone looks in the store,
> they would see it's a symlink too.
That only works if the new name is shorter than the old name though.
When the new name is longer (which is a more common case in our
experience when introducing package replacements, typically because the
new version string is longer), nothing can be done.
I’m tempting to keep things as is.
Thoughts?
Ludo’.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#43984: `--with-graft=...` doesn't work with packages of different length name/version
2020-10-15 7:50 ` Ludovic Courtès
@ 2020-10-15 18:50 ` pkill9
2020-10-16 9:31 ` Ludovic Courtès
0 siblings, 1 reply; 8+ messages in thread
From: pkill9 @ 2020-10-15 18:50 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 43984
> > Maybe if the length/version is different, then a symlink could be
> > created in the store pointing to the new dependency, with a
> > name/version that matches the length of the original dependency's
> > store name? Perhaps this new name/version could be something like
> > /gnu/store/...-original-dependency-name-gggggg, where 'g..' matches
> > the length of the version of the original dependency. The many 'g's
> > would make it clear that it is a graft. Then if someone looks in
> > the store, they would see it's a symlink too.
>
> That only works if the new name is shorter than the old name though.
> When the new name is longer (which is a more common case in our
> experience when introducing package replacements, typically because
> the new version string is longer), nothing can be done.
I'm confused about what you mean. Why would it matter if the new
name is longer than the old name?
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#43984: `--with-graft=...` doesn't work with packages of different length name/version
2020-10-15 18:50 ` pkill9
@ 2020-10-16 9:31 ` Ludovic Courtès
2020-10-17 1:03 ` pkill9
0 siblings, 1 reply; 8+ messages in thread
From: Ludovic Courtès @ 2020-10-16 9:31 UTC (permalink / raw)
To: pkill9; +Cc: 43984
pkill9 <pkill9@runbox.com> skribis:
>> > Maybe if the length/version is different, then a symlink could be
>> > created in the store pointing to the new dependency, with a
>> > name/version that matches the length of the original dependency's
>> > store name? Perhaps this new name/version could be something like
>> > /gnu/store/...-original-dependency-name-gggggg, where 'g..' matches
>> > the length of the version of the original dependency. The many 'g's
>> > would make it clear that it is a graft. Then if someone looks in
>> > the store, they would see it's a symlink too.
>>
>> That only works if the new name is shorter than the old name though.
>> When the new name is longer (which is a more common case in our
>> experience when introducing package replacements, typically because
>> the new version string is longer), nothing can be done.
>
> I'm confused about what you mean. Why would it matter if the new
> name is longer than the old name?
All I’m saying is that nothing can be done when the new name is longer
than the old one: we just cannot graft.
Ludo’.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#43984: `--with-graft=...` doesn't work with packages of different length name/version
2020-10-16 9:31 ` Ludovic Courtès
@ 2020-10-17 1:03 ` pkill9
2020-10-20 21:29 ` Ludovic Courtès
0 siblings, 1 reply; 8+ messages in thread
From: pkill9 @ 2020-10-17 1:03 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 43984
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#43984: `--with-graft=...` doesn't work with packages of different length name/version
2020-10-17 1:03 ` pkill9
@ 2020-10-20 21:29 ` Ludovic Courtès
2020-10-20 22:34 ` Mark H Weaver
0 siblings, 1 reply; 8+ messages in thread
From: Ludovic Courtès @ 2020-10-20 21:29 UTC (permalink / raw)
To: pkill9; +Cc: 43984
Hi,
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.
Ludo’.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#43984: `--with-graft=...` doesn't work with packages of different length name/version
2020-10-20 21:29 ` Ludovic Courtès
@ 2020-10-20 22:34 ` Mark H Weaver
2020-10-21 8:45 ` Ludovic Courtès
0 siblings, 1 reply; 8+ messages in thread
From: Mark H Weaver @ 2020-10-20 22:34 UTC (permalink / raw)
To: Ludovic Courtès, pkill9; +Cc: 43984
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#43984: `--with-graft=...` doesn't work with packages of different length name/version
2020-10-20 22:34 ` Mark H Weaver
@ 2020-10-21 8:45 ` Ludovic Courtès
0 siblings, 0 replies; 8+ messages in thread
From: Ludovic Courtès @ 2020-10-21 8:45 UTC (permalink / raw)
To: Mark H Weaver; +Cc: pkill9, 43984
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’.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-10-21 8:46 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-14 0:55 bug#43984: `--with-graft=...` doesn't work with packages of different length name/version pkill9
2020-10-15 7:50 ` Ludovic Courtès
2020-10-15 18:50 ` pkill9
2020-10-16 9:31 ` Ludovic Courtès
2020-10-17 1:03 ` pkill9
2020-10-20 21:29 ` Ludovic Courtès
2020-10-20 22:34 ` Mark H Weaver
2020-10-21 8:45 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).