[Nix-dev] deploying nix-built software to non-nix linux systems

Juho Östman sommite+nixdev at kapsi.fi
Mon Nov 10 15:46:00 CET 2014


10.11.2014, 15:20, Tomasz Kontusz kirjoitti:
> This might work, the question is: how many packages would really be
> relocatable?
> Many formats will lock or restrict the path's length based on the actual
> part used when building, or mangle it in a hard to spot ways
> (compression, multibyte encodings).
>
Some outputs are currently relocatable without any changes.
Many scripts and wrapped programs can relocated by rewriting the shebang 
line or the wrapper.
Some formats have special tools to rewrite the paths, for example, 
RPATHs in an ELF binary can be changed, even if they have different lengths.
Any paths that can be relative to the location of the file are 
relocatable, for example $ORIGIN references in an ELF binary and links 
in a format like HTML or XML.
The relative path can point to a symbolic link that in turn points to 
the actual target. Then the relocation script can replace the symbolic 
link when the target changes. For example, /nix/store/a/bin/program uses
the resource 'database' that is provided by another package. The 
hard-coded path to the database is relative to the location of the 
program: '../share/database'. It can be a symbolic link to the actual 
location '/nix/store/b/share/database'. If the program is relocated, it 
is easy to replace the symbolic link.

Outputs with hard-coded paths that have to be absolute and it is not 
practical to write a special tool for them are not relocatable.
In some cases it can still be easy enough to patch the upstream code, so 
that program does not need hard-coded paths or that the paths can be 
relative.

Best regards,
Juho Östman



More information about the nix-dev mailing list