guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Non-root Guix]: Unable to build guix


From: Mark H Weaver
Subject: Re: [Non-root Guix]: Unable to build guix
Date: Sat, 04 May 2019 20:39:18 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Hi Ricardo,

Ricardo Wurmus <address@hidden> writes:

> rohit yadav <address@hidden> writes:
>
>>> Do you want to build everything from source on your system or do you
>>> prefer to use binaries from the Guix project’s build farms?  Do you have
>>> access to user namespaces / can you use “unshare” for file system
>>> shenanigans?
>>>
>> I need to build guix for non-root location because at several places its
>> hard to convince to use such system. However, I need several packages which
>> are not usually available or outdated. The guix projects allows me to do
>> so. To accomplish that I need truly non-root permission oriented method to
>> bootstrap and install whatever I deem necessary for my use case.
>
> I see.  Unfortunately you will end up having to compile everything from
> source, C library, GCC,… — all of it.  When using a different store
> location it is impossible to use pre-built binaries, unfortunately.

If one is able to obtain write access to any directory accessible via an
absolute path name of no more than 10 bytes, e.g. "/tmp/xxxxx",
"/var/tmp/x", "/home/xx/x", or possibly even "/home/xxxx" or
"/home/xxx", then it may be possible to avoid compiling everything from
source code.

In principle, I believe it should be possible to rewrite all occurrences
of "/gnu/store" in our store outputs to another string of the same
length, or to a shorter string by adding redundant slashes.  Note that
one must take care to rewrite the targets of symbolic links as well.

Our grafting system already crucially depends on being able to reliably
find and rewrite store references, and therefore the Guix project is
naturally compelled to ensure that our package outputs encode store
references as plain byte strings.  For example, although we generally
prefer to minimize changes to upstream packages, we modified our C
compiler to avoid encoding string literals within immediate operands in
generated machine code, as upstream GCC will sometimes do on x86_64.

In summary, Guix has already laid the groundwork to support this kind of
rewriting of binaries, and we could put it to good use here.  I suggest
adding a mechanism to our offloading code that allows rewriting the
store prefix within downloaded binaries to a local store prefix of equal
or lesser length.

What do you think?

      Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]