Daniel Burrows <dburrows <at> debian.org> writes: >
Note: I'm not subscribed to the list, and pulling this old thread through Gmane; please CC directly to me. The purpose of this is to cross-examine Daniel's thoughts and bring new thoughts to the surface. Daniel's thoughts are valid; however my thoughts tend to be ... parasitic. My thought process tends to follow: - Can we use this? - Yes! Integrate it! - No, that's stupid, but this part looks interesting so let's rip that off The prior discussion of 2008 seems to have established that Nix isn't something Debian wants. So let's look at the tail end. I'll put the main proposal up front: I feel that being able to install multiple system profiles with dependency resolution is a good feature--i.e. the feature of Nix that lets one program see /usr/lib (or what is effectively its /usr/lib) as something entirely different from what another program sees. It shouldn't be a core, absolute feature. Instead, I think it's best to find the least-effort way to modify dpkg so that it: 1) Can handle running on a system managed like this; and 2) Provides an API to extend dpkg/apt to function this way In other words, add the capability for a plug-in that changes the way packaged files are stored and managed, and let somebody else hook up to the glue code and make it happen. Don't break Debian for the rest of us. That would appropriately increase aji and leave open many possibilities for the future. (For what it's worth, I don't like the direction Nix went in. Stick to managing packages and system layout; Nix goes all the way out to managing your configuration file CONTENTS, which among other things makes it completely useless in serious production cases--Nix wants to live in its own, rigid little world and not play well with others at all). > Hi there. As I'm sure everyone knows, I'm not exactly unbiased here > since I've done a lot of work on the apt system (although nix looks more > like a replacement for dpkg). [...] > > ==== > Nix stores packages in the Nix store, usually the directory /nix/store, > where each package has its own unique subdirectory such as > > /nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/ > ==== > > Never mind that this breaks the FHS -- I'll pretend for now that > we've amended policy to allow this, or that we've stuck it in /var > with some horrible bind-mounting to make it appear in the right places. > I've poked around in Nix. I find this not terrible, but the design decision of whether to put things in /var/system or whatnot is a design decision I don't care about. Fiddly bits. > That's a terrible user interface decision! This is Unix, and > filenames are part of the user interface. That file name, aside from > breaking all user expectations (as per my note about the FHS), is > completely unmemorable, means that packages with the same name aren't > necessarily sorted together in directory listings, breaks tab-completion, > and includes a long string of (to the user) meaningless gobbledygook. > At the very *least*, you should put the package name first, to fix the > tab-completion and sorting problems: > > /nix/store/firefox-2.0.0.1-r8vvq9kq18pz08v249h8my6r9vs7s0n3 > > but then what if I have two firefox-2.0.0.1s installed? How do I > know which one is which? > Mostly: Unimportant. Good question, but not that important. > I hope nix at least has stow-like abilities to create a unified /bin > directory, but that doesn't help when you want to track down the files > of a program for whatever reason. And this is why. In Nix, it appears you have /usr/bin/env and /bin/sh that are symlinks. Beyond that there is some sort of path to the current system that has a bin and lib directory filled with symlinks, all pointing to a whole lot of /nix/store/*/bin/* stuff. So, a horrible mess. The fact is, though, a "system image" is sort of constructed from a whole bunch of symlinks. You can find the real target via readlink -f, I think. In effect, if you look at 'which ls', it tells you where your system directory is. As I said right at the beginning: this nightmare is useful, but should be wholly elective and not a core part of dpkg/apt. > > ==== > Multiple versions > > You can have multiple versions or variants of a package installed at the > same time. This is especially important when different applications have > dependencies on different versions of the same package — it prevents the > “DLL hell”. Because of the hashing scheme, different versions of a package > end up in different paths in the Nix store, so they don’t interfere with > each other. > ==== > > That's fine as long as your hard drives (never mind the flash devices > embedded systems use, where dpkg is already painfully heavy) are infinitely > large, or you don't install very many versions of very many packages. This got me too. I think the best way to handle this would be to do a dependency resolution of all installed packages and remove old versions. That is to say: if you upgrade mysql, you have 3 applications that depend on various conflicting packages, and none of any of THAT leads to dependencies on the older version of mysql ... then remove that old version of mysql. Ubuntu--and I suspect Debian proper--have 'apt-get autoremove' to remove unneeded dependencies. A similar cleaning function would make sense in an environment like Nix proposes. > > ==== > An important consequence is that operations like upgrading or uninstalling > an application cannot break other applications, since these operations > never “destructively” update or delete files that are used by other > packages. > ==== > > That sounds like they haven't thought hard about the problems around > upgrades and removals, which are not trivial. (there's a research team > at the University of Paris they could talk to about this, if they > haven't already) Because of that, I suspect that we *can't* disable > the "install multiple versions" feature -- it sounds like the package > manager fundamentally relies on this to do anything. > This is a guarantee that should be removed. At some point we have to stop pretending that we can make changes to systems with zero risk. If you look at the Nix home page and relevant research papers, these folks have deluded themselves into the belief that they have discovered 100% security while allowing users to make administrative changes to the system. The belief that you can upgrade things with no risk is also delusional. > In addition to my earlier comments: what if I have multiple Web > servers or database servers installed (or multiple versions of one of > them)? Which one runs at startup, and what if I have packages that > specifically depend on another one? I think ideally you would have to accept that the start-up system is going to run whatever is the 'active' version of an application, by some mechanism. If you have postgresql 8.2 and 9.3 installed, your init script should reference one of these. In actuality, your system should reflect one of these--when you run psql, a particular binary is in your path. That binary resides with the postgresql server as well, and both are from the same version (unless, I guess, they come from different packages). While there would be a mechanism to run multiple postgresql server versions, the normal behavior would be current stuff. "Current" is flexible, but it means essentially that you have to not be schizophrenic and actually have one version of postgresql active. Due to the way Nix behaves, and the way a similar system would behave, it's not a far fetched idea to say that you could specify an application profile that lets you run postgresql 8.2, and have an init script that calls that, such that you have /etc/init.d/pgsql and /etc/init.d/pgsql-8.2; this is a later consideration. Specific forms possible include: - Multiple init scripts - A configuration file that specifies configuration for multiple versions - A configuration file that specifies init to call for multiple versions (with separate /etc configurations and separate init scripts) - A mechanism to switch to an application's profile, then activate its init script, and thus init would be aware that BOTH init scripts would be run I suspect that current init systems would balk at the last 2. > > ==== > Complete dependencies > ==== > No arguments here. The magic dependency gathering solutions are not my cup of tea. I would suggest the package manager would be aware of dependencies and take appropriate action, rather than relying on fuzzy logic. > > ==== > Garbage collection > ==== > > That's great, as long as they include the ability for me to say "I > really want to remove firefox, please show me all the packages that are > keeping it on my system." Of course, we already have that in Debian. Agree. We have dependency resolution and we can re-install stuff from packages. No need for stuff hanging around "just in case". > > ==== > Multi-user support > > Starting at version 0.11, Nix has multi-user support. This means that > non-privileged users can securely install software. Each user can have a > different profile, a set of packages in the Nix store that appear in the > user’s PATH. If a user installs a package that another user has already > installed previously, the package won’t be built or downloaded a second > time. At the same time, it is not possible for one user to inject a Trojan > horse into a package that might be used by another user. > ==== > > I like this, and I've thought from time to time about how we could > theoretically integrate it into dpkg. I'm a little worried about the > interaction with garbage collection: it sounds to me like a normal user > can DoS the system by depending on someone else's package so that it > never gets garbage collected. Agree, although it depends somewhat on Nix-like behavior or on front-loading the user's PATH with PATH=/usr/local/users/$ME/usr/bin not to mention /etc, /lib, and so on. It's also a feature many of us simply do not want. Just like all Nix-like behavior. > With all that said, I think that Nix is a useful program, both because > it explores some new ideas in package management, and also because I can > see it being very useful in some niche areas where current package > managers are lacking. And therein is my point: It's a cute exploratory program, but it doesn't fit in with the needs of most people and is immature. Taking lessons from these sorts of explorations is a good thing. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130223t172732-...@post.gmane.org