[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