Artyom Shalkhakov wrote: > 2008/12/24 Eugene V. Lyubimkin <jackyf.devel@gmail.com>: >> Which means that "find all dependencies with no exceptions" is not true. > > This is how Nix developers put it: > >> Runtime dependencies are found by scanning binaries for the hash parts >> of Nix store paths (such as r8vvq9kq…). This sounds risky, but it works >> extremely well. > (See <http://nixos.org/about.html>, section called "Complete dependencies".) I read this part, however I haven't understand it. Nix creates cryptographic hashes, ok, and how can this work for runtime deps? Shared libraries are best found by ldd, but most of other stuff still cannot be deduced, because binary obviously doesn't contain these hashes. >> If edited by administrator config file was deleted, then or it cannot be >> reverted, or it was not purged. Most other stuff can be reverted in theory... >> but again, Debian package maintainer scripts don't support downgrading (in >> general), and there are reasons for it. > > Take another point of view: every Nix package exists in an ideal world where the > only packages it knows about are it's dependencies (and their precise versions). So, Nix will install packages (i.e. files) to non-standard directories. Who will patch programs to look not in /etc/<package>.conf, but in /nix/...? Same question about /usr/share. Keep in mind that Debian policy explicitly forbid using non-FHS paths by packages. Packages that don't obey this must be patched or leave Debian. I doubt Nix can get an exception from this rule. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com Ukrainian C++ Developer, Debian Maintainer, APT contributor
Attachment:
signature.asc
Description: OpenPGP digital signature