[Nix-dev] Packaging software that mutates itself
Nikita Karetnikov
nikita at karetnikov.org
Fri May 6 00:02:15 CEST 2016
I've talked a bit about this on IRC earlier today, but I think the issue
deserves an in-depth discussion. It's more of a general policy question, a
clash of an imperative world and a pure functional one. I'm trying to package a
Java program, a client, which can be (among other things) updated by the server.
At first, I put everything into the store, but then the client received an
update command from the server and attempted to create a directory in the store
(probably based on the program location), which failed. The program is
proprietary, so I tried to find a way to change this behavior in the docs, but
there doesn't seem to be any way to do it. And it wouldn't solve the issue
anyway. The server is controlled by other people. Even if I find a way to
solve this for this particular version, e.g., by putting some files into a
mutable directory (more on this below), the new client version, which will be
installed by the server, might contain other unexpected features, which might
prevent the client from operating properly.
Has anyone packaged something like this? What's a proper way to solve this
without compromising the integrity of a system (think of potential security
issues or just proper operation)? NixOS supports containers, but I haven't used
them yet, can it be the answer? What would be an expected mutable location for
something like this? There's, for instance, /var/lib as described in
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION, but
I can't even use it since that requires sudo, which is a no go for a build
script. I need to copy the files into a mutable directory at build time (I'm
using the builder.sh way as described in the Nixpkgs manual).
More information about the nix-dev
mailing list