[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24703: Store references in 8-byte chunks in compiled code
From: |
Ludovic Courtès |
Subject: |
bug#24703: Store references in 8-byte chunks in compiled code |
Date: |
Thu, 20 Oct 2016 14:25:01 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Török Edwin <address@hidden> skribis:
> On 2016-10-17 12:42, Mark H Weaver wrote:
>>
>> Here's how to recover, for now:
>>
>> guix build --no-grafts -e '(@@ (gnu packages fontutils) fontconfig/fixed)'
>
> Thanks!
>
> On 2016-10-17 15:09, Ludovic Courtès wrote:
>> Török Edwin <address@hidden> skribis:
>>
>>> On 2016-10-16 22:04, Ludovic Courtès wrote:
>>>> Mark H Weaver <address@hidden> skribis:
>>>>
>>>>> When grafting, how will we achieve confidence that we've found the
>>>>> correct occurrence of the last character? I think we will have to give
>>>>> up our recently added feature of being able to change the version number
>>>>> of grafts.
>>>>
>>>> Wait, don’t jump to the conclusions. :-)
>>>
>>> I've just encountered the same problem with fontconfig (after installing
>>> GuixSD, running guix pull and guix system reconfigure, --no-grafts was
>>> required).
>>> Would it be possible for the grafts to keep a symlink (somehow registered
>>> to be part of the grafted fontconfig so that guix gc doesn't remove it)
>>> instead of patching the binaries?
>>> /gnu/store/<old-hash>-fontconfig-2.11.94 ->
>>> /gnu/store/<grafted-hash>-fontconfig-2.11.94
>>
>> We could use a self symlink
>
> I'm new here [*] and I'd like to understand what solutions would be possible,
> could you please explain how the self symlink would work?
The grafted variant of each store item would have a symlink pointing to
its ungrafted variant.
The problem with this approach is that it would induce some storage
overhead (although deduplication probably mitigates that), and it would
make it harder to check whether a given item is using only grafted
things because ‘guix gc -R something’ would always show both the grafted
and the ungrafted variant of each dependency.
> I was thinking about bind mounts (the list of needed bind mounts would be
> maintained as a derivation, and initialized from initrd maybe?):
> /gnu/store/<new-hash>-fontconfig-2.11.94 on
> /gnu/store/<old-hash>-fontconfig-2.11.94
That would only work on GuixSD, not on foreign distros, and it’s a
“stateful” approach, which defeats the whole reproducible approach.
> IMHO binary rewriting should be a last resort, it is too low-level and
> depends on the compiler/version to get it right.
I agree. However, for fast security updates, it seems to be the best
option:
https://savannah.gnu.org/forum/forum.php?forum_id=8470
Thanks for your feedback,
Ludo’.
- bug#24703: Re: bug#24703: Store references in 8-byte chunks in compiled code, (continued)
- bug#24703: Re: bug#24703: Store references in 8-byte chunks in compiled code, Török Edwin, 2016/10/17
- bug#24703: Re: bug#24703: Store references in 8-byte chunks in compiled code, Mark H Weaver, 2016/10/17
- bug#24703: Store references in 8-byte chunks in compiled code, Ludovic Courtès, 2016/10/17
- bug#24703: Store references in 8-byte chunks in compiled code, Mark H Weaver, 2016/10/17
- bug#24703: Store references in 8-byte chunks in compiled code, Ludovic Courtès, 2016/10/18
- bug#24703: Store references in 8-byte chunks in compiled code, Mark H Weaver, 2016/10/31
- bug#24703: Store references in 8-byte chunks in compiled code, Ludovic Courtès, 2016/10/31
- bug#24703: Store references in 8-byte chunks in compiled code, Leo Famulari, 2016/10/24
- bug#24703: Store references in 8-byte chunks in compiled code, Ludovic Courtès, 2016/10/24
- bug#24703: Store references in 8-byte chunks in compiled code, Török Edwin, 2016/10/19
- bug#24703: Store references in 8-byte chunks in compiled code,
Ludovic Courtès <=
bug#24703: fontconfig keeps obfuscated reference to itself, not grafted, Ludovic Courtès, 2016/10/16