Re: Adoption of Nix?
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
Re: Adoption of Nix?
Hello Just some quick notes related to this, without jumping in to the discussion (yet?). On 24 February 2013 01:28, John Moser john.r.mo...@gmail.com wrote: 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 Burrows is not active in Debian for some time, and should perhaps not be expected to partake in the resumed discussion. 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. Nix operates fairly indepently of the underlying system. There is no pressing need for dpkg–nix integration at this point, indeed, that is a can of worms. To briefly illustrate: Debian packages are each built with specific configurations (enabled features, etc.), call this a build profile. When one Debian package declares a dependency on an other, it is with the implicit knowledge that a particular build profile or feature set is provided. Nix allows multiple builds of the same package–version to be installed with different, and arbitrary build profiles, and allows other packages to depend on exactly the features they require in the profile. Without a map from Debian package–version to build profiles, there is no way to reliably know whether a particular Nix build either satisfies a Debian package dependency, or has one of its dependencies satisfied by an installed Debian package. For this reason, I believe it is not viable to integration Nix and dpkg, and the two should be thought of as independent systems: dpkg has installed your main (or base) system, and a user is free to layer any Nix packages on top. Nix packages installed in per-user profiles will not generally interfere with Debian packages. Unfortunately, there will be some waste as Nix duplicates a small set of base dependencies (gcc, etc.). Though you could avoid this with a nix-base package that depends on the equivalent Debian packages and provides Nix the information that certain package–version–build-profiles are installed. That would appropriately increase aji and leave open many possibilities for the future. aji? (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). Right. A good reason to keep it separate. 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). Since this old discussion there is now also Guix http://gnu.org/software/guix/ constructed on top of Nix that provides some nicer interfaces. Think of it as operating at the apt level, I suppose. Thats all for now. -- 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/can3verdqjuemc7c87dzechrv9az7t+kwupa4b+59q0cjyh3...@mail.gmail.com
Re: Adoption of Nix?
On 02/23/2013 07:45 PM, Daniel Hartwig wrote: Hello Just some quick notes related to this, without jumping in to the discussion (yet?). On 24 February 2013 01:28, John Moser john.r.mo...@gmail.com wrote: 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 Burrows is not active in Debian for some time, and should perhaps not be expected to partake in the resumed discussion. I was just trying to not start anew, but rather revisit. Without a map from Debian package–version to build profiles, there is no way to reliably know whether a particular Nix build either satisfies a Debian package dependency, or has one of its dependencies satisfied by an installed Debian package. For this reason, I believe it is not viable to integration Nix and dpkg, and the two should be thought of as independent systems: dpkg has installed your main (or base) system, and a user is free to layer any Nix packages on top. Nix packages installed in per-user profiles will not generally interfere with Debian packages. Right, and that's why I proposed manipulating Apt and Dpkg such that they can understand and behave within a system with multiple installed versions managed in various places. To be clear, I don't think Nix is salvageable. That's why there was a big run about the whole project running off into la-la land with the ferrets. Instead I want dpkg itself to: 1) Competently handle situations where multiple versions of a package may be installed and managed in a Nix-like way; and 2) Expose a programming API so that someone can later provide a plug-in to extend dpkg with Nix-like behavior The existing software out there for this should never, ever be used. It is terminally broken. I think (1) and (2) would be a more minimal task, and would also provide a better framework for full multi-arch support (something somewhat lacking in dpkg last I checked, whereas RPM seems to have an infectious disease where x86_64 archs one day install a .i686 package for some unknown reason and then begin installing .i686 EVERYTHING whenever you install any package... okay, so THEY have working multi-arch support, I guess). That would appropriately increase aji and leave open many possibilities for the future. aji? Available entropy such that the flexibility to follow new possibilities and gain a stronger position continues to exist. The goal is to open a possibility, without imposing a new constraint. -- 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/51296550.3020...@gmail.com
Re: Adoption of Nix?
On 24 February 2013 08:56, John Moser john.r.mo...@gmail.com wrote: Right, and that's why I proposed manipulating Apt and Dpkg such that they can understand and behave within a system with multiple installed versions managed in various places. Thanks for clarifying so promptly. -- 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/can3verfcsrgehaqscqkq09dkehx7bx2ro2ujp2tflfnd8dw...@mail.gmail.com
Re: Adoption of Nix?
On Wed, Dec 24, 2008 at 03:08:20PM +0600, Artyom Shalkhakov wrote:
Cite from the homepage:
Nix is a purely functional package manager. It allows multiple
Hi all, I've studied a bit NixOS and written something about its
problems in a recent paper [1] (last paragraph of section
3). Interestingly enough, all the critics I've raised have been
confirmed by the authors of Nix, which I've met at the HotSWUp
workshop this year.
Summarizing the main objections I've raised against Nix are:
- a weird intermix between build-time dependencies and runtime
configuration, both in some cases get mixed into arguments to the
build functions, while it is clear that in Debian we prefer a more
clear distinction among the two
- not everything which compose a distribution can be made functional,
by the authors' own admission. The solution to similar problem is
in some case just living with that (e.g., while updating the user
database), in some other cases they just get rid of the
non-functional part.
It is for example the case of the ldconfig cache, they just live
without that. Such approach is surely interesting for the properties
you gain (atomicity of upgrades), but not something I want in a
production system. Also consider that they have packaged _way_ less
software than Debian, it is likely that more and more inherently
imperative parts of a system will be found by packaging more stuff.
- the garbage collection thingy (as other already observed in this
thread) is a PITA for security as you cannot completely get rid of
security flawed code (or, if you do that you loose the applications
never break property)
- maintainer scripts are not turned in functional (and revertible)
expressions, so the only way to undo them is living without them,
or restore whole parts of the filesystem (with the disk consumption
problems other observed)
All in all, the authors are conducing a (really nice!) experiment, but
they are aware themselves that it is not ready to scale to a system of
the size of Debian.
What is, IMO, way more interesting for us is the evolution of DistNix,
a distributed version of the Nix package manager (think, e.g., at
upgrading of cluster of machines all together) [2]. What they have in
that part of their system is a language for specifying assignments of
services (data-base, web server, MTA, ...) to machines and
inter-machine dependencies. Those information are used to guide
cluster upgrades granting transactional properties.
Unfortunately (for us) the needed underlying assumption is that
upgrades on the single machines are transactional, which is not
something we can currently grant on top of APT.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Adoption of Nix?
On Sun, Dec 28, 2008 at 11:57:09AM +0100, Stefano Zacchiroli wrote:
problems in a recent paper [1] (last paragraph of section
snip
upgrading of cluster of machines all together) [2]. What they have in
Dangling references:
[1] http://upsilon.cc/~zack/research/publications/hotswup-package-upgrade.pdf
[2] http://www.st.ewi.tudelft.nl/~dolstra/pubs/atomic-hotswup2008-submitted.pdf
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Adoption of Nix?
Artyom Shalkhakov wrote: Hello, Hello, Nix is a purely functional package manager. It allows multiple versions of a package to be installed side-by-side, ensures that dependency specifications are complete, supports atomic upgrades and rollbacks, allows non-root users to install software, and has many other features. The claims that I think are valuable are: - *all* dependencies of a package are automatically found by Nix, no exceptions, Hmm... Nix probably use libastral, doesn't it? Even for C/C++ programs there is no way to 100% automatically determine entire list of runtime libraries/tools needed for some particular program (consider runtime library opening and all non-library dependencies). - updates and rollbacks are atomic, an update can never break your system. This cannot be true. Consider package maintainer scripts. And, for example. purge of config files cannot be reverted. What do you think of adopting Nix as a package management tool for Debian? I would like to accentuate that I seek an informative discussion, not a holy war. Nix, as mentioned on its homepage, installs some info in /nix (hey, FHS) and keeping all versions of packages/libraries - system bloat and a hell for security team. It has nothing to do with our apt infrastructure, it doesn't understand it and invented its own wheel. I think no way for Nix in Debian. We have excellent dpkg, we have not-so-excellent, but rather good apt, and significant amount of Debian users choose Debian just only because of apt. IMO. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com Ukrainian C++ Developer, Debian Maintainer, APT contributor signature.asc Description: OpenPGP digital signature
Re: Adoption of Nix?
Hi Eugene, 2008/12/24 Eugene V. Lyubimkin jackyf.de...@gmail.com: The claims that I think are valuable are: - *all* dependencies of a package are automatically found by Nix, no exceptions, Hmm... Nix probably use libastral, doesn't it? Even for C/C++ programs there is no way to 100% automatically determine entire list of runtime libraries/tools needed for some particular program (consider runtime library opening and all non-library dependencies). This is not about libastral, it's about pure functions (those without side-effects). Regarding runtime library opening (I suppose, you meant dlopen and friends), then I suppose, you've found an exception to the rule, but maybe you are wrong. I'm not a developer of Nix, so I can't say more. - updates and rollbacks are atomic, an update can never break your system. This cannot be true. Consider package maintainer scripts. And, for example. purge of config files cannot be reverted. It can always be reverted if you don't destructively update (overwrite) files and if you can guarantee that filenames do not clash. It has nothing to do with our apt infrastructure, it doesn't understand it and invented its own wheel. I think no way for Nix in Debian. We have excellent dpkg, we have not-so-excellent, but rather good apt, and significant amount of Debian users choose Debian just only because of apt. IMO. I'm not interested in your opinion if it isn't backed by facts, I'm interested in *informative discussion*. I don't say that dpkg/apt are bad, on the contrary, I think they are good, but we aren't talking about personal tastes. It looks like you completely misunderstood the idea, so lurk before you post. Thanks. Cheers, Artyom Shalkhakov. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Adoption of Nix?
On Wed, Dec 24, 2008 at 05:17:28PM +0600, Artyom Shalkhakov wrote: It looks like you completely misunderstood the idea, so lurk before you post. Thanks. You can't post a two-sentence summary of a new package manager to debian-devel, say discuss and then shoot down replies by claiming the person has not done any research. If you want to be taken serious, write a paper about Nix and/vs. dpkg/apt, and post the link to it here together with an introductory summary/abstract or something. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Adoption of Nix?
Le mercredi 24 décembre 2008 à 17:17 +0600, Artyom Shalkhakov a écrit : It has nothing to do with our apt infrastructure, it doesn't understand it and invented its own wheel. I think no way for Nix in Debian. We have excellent dpkg, we have not-so-excellent, but rather good apt, and significant amount of Debian users choose Debian just only because of apt. IMO. I'm not interested in your opinion if it isn't backed by facts Which facts are you missing? * Nix doesn’t follow the FHS and invents its own filesystem hierarchy instead. * Nix keeps all versions of all packages installed; this not a feature but a bug, and quite a serious one. * Nix doesn’t allow to transparently replace a library by a newer version, which is an even more critical issue, which makes it impossible to remotely consider its use on production machines. * The implementation sounds full of gross hacks (like grepping all files for the hash of the directory with dependencies). * Installing each package in its own directory means that no shared configuration and no preservation of configuration upon upgrades. Furthermore, even if it wasn’t as badly flawed, you seem to be underestimating the amount of work to change a package manager in a distribution. Any changes to the package manager must be backwards-compatible. If you want to do something useful, I suggest that you grab the interesting ideas from nix (like binary deltas) and propose patches for APT to implement them. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Adoption of Nix?
Artyom Shalkhakov wrote: Hmm... Nix probably use libastral, doesn't it? Even for C/C++ programs there is no way to 100% automatically determine entire list of runtime libraries/tools needed for some particular program (consider runtime library opening and all non-library dependencies). This is not about libastral, it's about pure functions (those without side-effects). Regarding runtime library opening (I suppose, you meant dlopen and friends), then I suppose, you've found an exception to the rule, but maybe you are wrong. I'm not a developer of Nix, so I can't say more. There are packages which runtime dependencies cannot be determined without looking to source code or contacting the author/looking to the home page. I maintains such a package. dlopen and friends is another example. Which means that find all dependencies with no exceptions is not true. - updates and rollbacks are atomic, an update can never break your system. This cannot be true. Consider package maintainer scripts. And, for example. purge of config files cannot be reverted. It can always be reverted if you don't destructively update (overwrite) files and if you can guarantee that filenames do not clash. 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. It has nothing to do with our apt infrastructure, it doesn't understand it and invented its own wheel. I think no way for Nix in Debian. We have excellent dpkg, we have not-so-excellent, but rather good apt, and significant amount of Debian users choose Debian just only because of apt. IMO. I'm not interested in your opinion if it isn't backed by facts, One big fact is: Debian have tens (or even hundreds) of tools that use apt infrastructure, including both user side and archive maintenance side. Nix, in any way it operates, suggests other API to maintain packages. Who is supposed to rewrite all this stuff for Nix? It looks like you completely misunderstood the idea, so lurk before you post. Thanks. Yes, you are probably right: I don't understand how Nix may be useful for Debian (and for GNU/Linux also). -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com Ukrainian C++ Developer, Debian Maintainer, APT contributor signature.asc Description: OpenPGP digital signature
Re: Adoption of Nix?
On Wed, Dec 24, 2008 at 8:42 PM, Josselin Mouette j...@debian.org wrote: If you want to do something useful, I suggest that you grab the interesting ideas from nix (like binary deltas) and propose patches for APT to implement them. Debian already has binary deltas (debdelta), but it isn't well integrated into apt (#498778). It also (understandably) supported on the ftp-master/mirrors side. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Adoption of Nix?
Hello. While I was writing, Josselin Mouette said almost all I wanted to say, but I'll add a little :) 2008/12/24 Artyom Shalkhakov artyom.shalkha...@gmail.com: The claims that I think are valuable are: - *all* dependencies of a package are automatically found by Nix, no exceptions, Hmm... Nix probably use libastral, doesn't it? Even for C/C++ programs there is no way to 100% automatically determine entire list of runtime libraries/tools needed for some particular program (consider runtime library opening and all non-library dependencies). This is not about libastral, it's about pure functions (those without side-effects). Well, as I see, it uses it's own package format, which is wrapper-description around everything - source, deb or rpm. Does it really have any sense? We have our deb and src packages, do we really need any wrappers, that make us possible to install rpms? For what purposes? Surely, dpkg always allows you to rollback any installed packages. You just sometimes have to rollback half of all your packages - in accordance with dependencies. I've just looked to the structure of that package format - it also requires to write dependencies - so what in it deals with 'em better? I really don't understand. Can it work with sections like Recommends or Suggests? And, of course, for the 2-3 versions of each package will make debian security team curse you for ages. Consider it :) -- Best wishes, Velichko Vsevolod -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Adoption of Nix?
Sorry, I forgot to forward this to debian-devel. -- Forwarded message -- From: Artyom Shalkhakov artyom.shalkha...@gmail.com Date: 2008/12/24 Subject: Re: Adoption of Nix? To: Eugene V. Lyubimkin jackyf.de...@gmail.com 2008/12/24 Eugene V. Lyubimkin jackyf.de...@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.) 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). One big fact is: Debian have tens (or even hundreds) of tools that use apt infrastructure, including both user side and archive maintenance side. Nix, in any way it operates, suggests other API to maintain packages. Who is supposed to rewrite all this stuff for Nix? You're probably right: nobody is going for a full rewrite. I guess I should inspect both Nix and dpkg more closely, and if I can find a one-to-one mapping between the two, then we can go for an automatic migration. Yes, you are probably right: I don't understand how Nix may be useful for Debian (and for GNU/Linux also). That's too bad for you. Shallow thinking doesn't get you anywhere. Cheers, Artyom Shalkhakov.
Re: Adoption of Nix?
Sorry, I forgot about the debian-devel for the second time. :( -- Forwarded message -- From: Artyom Shalkhakov artyom.shalkha...@gmail.com Date: 2008/12/24 Subject: Re: Adoption of Nix? To: Всеволод Величко torkvem...@nigma.ru Hi Vsevolod, 2008/12/24 Всеволод Величко torkvem...@nigma.ru: Well, as I see, it uses it's own package format, which is wrapper-description around everything - source, deb or rpm. Does it really have any sense? Every problem in computer science can be solved by adding a layer of indirection, as the saying goes. We have our deb and src packages, do we really need any wrappers, that make us possible to install rpms? For what purposes? Surely, dpkg always allows you to rollback any installed packages. You just sometimes have to rollback half of all your packages - in accordance with dependencies. I've just looked to the structure of that package format - it also requires to write dependencies - so what in it deals with 'em better? I really don't understand. The difference is *purity*, which means that Nix expressions are *deterministic*. And that's what really makes them better. Can it work with sections like Recommends or Suggests? I don't know this yet, but I think it's nearly trivial to add. And, of course, for the 2-3 versions of each package will make debian security team curse you for ages. Consider it :) Thanks for the advice, point taken. :) Cheers, Artyom Shalkhakov. PS do you work for Nigma, an intelligent search engine?
Re: Adoption of Nix?
Artyom Shalkhakov wrote: 2008/12/24 Eugene V. Lyubimkin jackyf.de...@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 signature.asc Description: OpenPGP digital signature
Re: Adoption of Nix?
Quoth Artyom Shalkhakov artyom.shalkha...@gmail.com, on 2008-12-24 17:17:28 +0600: It looks like you completely misunderstood the idea, so lurk before you post. Thanks. Debian List Search, list devel, author match artyom shalkhakov: two matches, all in this thread, not including your most recent two messages, also in this thread. Earliest post date: today. (I'm not a prolific d-d poster myself---mostly a lurker---but I also don't grant myself the social authority to drop lurk before you post on people's heads.) Quoth Artyom Shalkhakov artyom.shalkha...@gmail.com, on 2008-12-24 22:17:35 +0600: That's too bad for you. Shallow thinking doesn't get you anywhere. And a purity war against a huge established packaging system base won't get you much of anywhere either unless you're willing to do an awful lot of the work and demonstrate that the result is both superior in practice and sufficiently continuous that it's not just an entirely different system. (Actually, realistically, I think you're unlikely to get anywhere with this regardless, for other reasons.) Quoth Artyom Shalkhakov artyom.shalkha...@gmail.com, on 2008-12-24 15:08:20 +0600: I would like to accentuate that I seek an informative discussion, not a holy war. Yet I see practical issues being raised, and responses mainly accusing them of completely misunderstanding and shallow thinking. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Adoption of Nix?
Hi. 2008/12/24 Artyom Shalkhakov artyom.shalkha...@gmail.com: Well, as I see, it uses it's own package format, which is wrapper-description around everything - source, deb or rpm. Does it really have any sense? Every problem in computer science can be solved by adding a layer of indirection, as the saying goes. Yep, and the next year we'll introduce new level of abstraction - for different versions of nix package format. Pluralitas non est ponenda sine necessitate, said Occam, as I remember. We have our deb and src packages, do we really need any wrappers, that make us possible to install rpms? For what purposes? Surely, dpkg always allows you to rollback any installed packages. You just sometimes have to rollback half of all your packages - in accordance with dependencies. I've just looked to the structure of that package format - it also requires to write dependencies - so what in it deals with 'em better? I really don't understand. The difference is *purity*, which means that Nix expressions are *deterministic*. And that's what really makes them better. I see nothing purer in them. Show the difference, please. Can it work with sections like Recommends or Suggests? I don't know this yet, but I think it's nearly trivial to add. But it's not still added, really? And how about packaging many binary packages from the one source? PS do you work for Nigma, an intelligent search engine? Yes, I'm developer there. :) -- Best wishes, Velichko Vsevolod -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Adoption of Nix?
Yes, you are probably right: I don't understand how Nix may be useful for Debian (and for GNU/Linux also). That's too bad for you. Shallow thinking doesn't get you anywhere. As promoter/recommender surely the onus is upon you to demonstrate: 1. Nix is good. 2. Nix is better than what currently exists. 3. Nix would be a good fit for Debian. I believe you'll struggle, not least because you do not seem to have a thorough understanding of what is actually involved in a packaging system. (Perhaps a comparison to the auto-package format is in order?) Steve -- # The Debian Security Audit Project. http://www.debian.org/security/audit -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Adoption of Nix?
On Wednesday 24 December 2008 18:55:20 Steve Kemp wrote: Yes, you are probably right: I don't understand how Nix may be useful for Debian (and for GNU/Linux also). That's too bad for you. Shallow thinking doesn't get you anywhere. As promoter/recommender surely the onus is upon you to demonstrate: 1. Nix is good. 2. Nix is better than what currently exists. 3. Nix would be a good fit for Debian. Hm, Nix seems to be born in academia, and based on by someone's PhD thesis, so there might be some good ideas to consider out of it, but the whole story smells like the promoter is trying to sell mercedeses to Daimler (i.e. package management to Debian;-) without getting the whole picture. I believe you'll struggle, not least because you do not seem to have a thorough understanding of what is actually involved in a packaging system. (Perhaps a comparison to the auto-package format is in order?) If the promoter doesn't mind I'd also suggest comparision to the openpkg.org. citationGuess he wasn't too popular at the end, huh?/citation -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Adoption of Nix?
On 12/24/08 10:55, Drake Wilson wrote: Quoth Artyom Shalkhakov artyom.shalkha...@gmail.com, on 2008-12-24 17:17:28 +0600: It looks like you completely misunderstood the idea, so lurk before you post. Thanks. Debian List Search, list devel, author match artyom shalkhakov: two matches, all in this thread, not including your most recent two messages, also in this thread. Earliest post date: today. (I'm not a prolific d-d poster myself---mostly a lurker---but I also don't grant myself the social authority to drop lurk before you post on people's heads.) Quoth Artyom Shalkhakov artyom.shalkha...@gmail.com, on 2008-12-24 22:17:35 +0600: That's too bad for you. Shallow thinking doesn't get you anywhere. And a purity war against a huge established packaging system base won't get you much of anywhere either unless you're willing to do an awful lot of the work and demonstrate that the result is both superior in practice and sufficiently continuous that it's not just an entirely different system. (Actually, realistically, I think you're unlikely to get anywhere with this regardless, for other reasons.) Quoth Artyom Shalkhakov artyom.shalkha...@gmail.com, on 2008-12-24 15:08:20 +0600: I would like to accentuate that I seek an informative discussion, not a holy war. Yet I see practical issues being raised, and responses mainly accusing them of completely misunderstanding and shallow thinking. This is the kind of foolishness I pulled when I was fresh out of Uni and thought Academia knew everything. -- Ron Johnson, Jr. Jefferson LA USA I like my women like I like my coffee - purchased at above-market rates from eco-friendly organic farming cooperatives in Latin America. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Adoption of Nix?
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). This is the same package manager that was posted on lambda-the-ultimate a while back, right? Since you didn't provide a link, I'll provide one. According to Google, we're talking about this: http://nixos.org My first impression from reading blurbs on news sites was that they either found some seriously deep magic, or they're ignoring a lot of the practical issues that are involved in managing packages within a large Linux distribution -- and I suspect the latter rather than the former. As an academic research project, they are within their rights to do that, and for some use cases it doesn't matter, but it doesn't mean we should adopt their software in Debian. To take a few excerpts from their site: 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. 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? 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. 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. The thought of doing this to track unstable terrifies me; I suspect that even a large hard drive would fill up a few weeks, months tops. And you can't automatically purge versions, because you never know which ones a user wants. Presumably there's a way to turn this off. In fact, I would expect that we *would* turn this off by default, with a manual override for particular packages, if we used it in Debian, because I can't see it being usable for a whole distribution otherwise. On the other hand: 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. 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? Complete dependencies As other people have written, their claims are at best overblown. e.g., while it can tell that I use Python, there's no possible way it can tell which versions of Python I'm compatible with. It also sounds like maybe they bind programs to the exact binary of the library they're built with, which would mean that you have to rebuild all the reverse dependencies of a library every time you rebuild the library! (that's so outrageous that I'm sure I must just be incorrectly extrapolating from the summary on their Web site) Also: what about programs that refer to a file, but can function without it? This seems to have the same problem as other harnesses that automatically detect dependencies through file access, in that it will see a program probing for some functionality
Re: Adoption of Nix?
In article 200812241947.08458.danc...@spnet.net you wrote: Hm, Nix seems to be born in academia, and based on by someone's PhD thesis, so there might be some good ideas to consider out of it, but the whole story smells like the promoter is trying to sell mercedeses to Daimler (i.e. package management to Debian;-) without getting the whole picture. There are quite a lot home grown package managment systems offering versioned program directoris. Nix is not the only one doing that. Those are especially used in academia where larger multi user shell servers are common. Greetings Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
