I thought folks on this list would be interested to read this article about Nix:
http://www.linux.com/feature/155922
How does this compare with openSUSE efforts to solve the same kinds of problem?
-Archie
-- Archie L. Cobbs
Archie Cobbs escribió:
How does this compare with openSUSE efforts to solve the same kinds of problem?
What is your specific question ? what has NIX a package manager done primarily for source based installations with the needs of openSUSE, a binary distribution ?
Dont tell me that the so called dependency hell is the blame of package manager please.
On Fri, Mar 6, 2009 at 10:37 AM, Cristian Rodríguez crrodriguez@suse.de wrote:
How does this compare with openSUSE efforts to solve the same kinds of problem?
What is your specific question ? what has NIX a package manager done primarily for source based installations with the needs of openSUSE, a binary distribution ?
I ask because I've found myself in the situation described in the article: afraid to upgrade, because of past bad experiences and the knowledge that stuff I've built on my machine will break, and instead waiting for the next hard disk crash when I will have to reinstall anyway :-)
On the other hand, I would be happy to hear that I'm being too pessimistic about the openSUSE upgrade process and why. How should one avoid dependency hell? Maybe I'm doing it all wrong.
A simple example: I have an old SLES9 machine. It still works great and I use it every day. However, when I tried upgrading my Firefox 2.x to 3.x, it quickly became impossible and I gave up (there is no pre-built Firefox 3.x for SLES9 in OBS). I don't want to have to download the Firefox source and build it manually. Of course, you can forget trying to upgrade SLES9 to SUSE 11.x and have everything continue to work (why should I be forced to do that anyway?). So this is "the problem".
More generally, I get the feeling that the openSUSE "power users" stay on the bleeding edge, so they don't get as much first-hand experience with (and empathy for) problem situations like my example.
Dont tell me that the so called dependency hell is the blame of package manager please.
I wouldn't say that. But I wouldn't say that dependency hell has been banished from the earth yet either. The fact is that there seems to be a need for a tool like Nix, so it just makes you think: why is this tool needed? What is causing the problem? What is the right way to solve the problem and how can we encourage and support a solution? Etc.
-Archie
-- Archie L. Cobbs
Archie Cobbs schrieb:
A simple example: I have an old SLES9 machine. It still works great and I use it every day. However, when I tried upgrading my Firefox 2.x to 3.x, it quickly became impossible and I gave up (there is no pre-built Firefox 3.x for SLES9 in OBS). I don't want to have to download the Firefox source and build it manually. Of course, you can forget trying to upgrade SLES9 to SUSE 11.x and have everything continue to work (why should I be forced to do that anyway?). So this is "the problem".
A little bit offtopic to the main but for your example. There is a reason there is no Firefox 3 for SLES9. It's simply not possible to build it since Gtk+ on SLES9 is so old that Firefox 3 refuses to build (and run). Nix (whatever this is) wouldn't help you in that case I guess.
Wolfgang
On Fri, Mar 6, 2009 at 12:55 PM, Wolfgang Rosenauer wolfgang@rosenauer.org wrote:
Archie Cobbs schrieb:
A simple example: I have an old SLES9 machine. It still works great and I use it every day. However, when I tried upgrading my Firefox 2.x to 3.x, it quickly became impossible and I gave up (there is no pre-built Firefox 3.x for SLES9 in OBS). I don't want to have to download the Firefox source and build it manually. Of course, you can forget trying to upgrade SLES9 to SUSE 11.x and have everything continue to work (why should I be forced to do that anyway?). So this is "the problem".
A little bit offtopic to the main but for your example. There is a reason there is no Firefox 3 for SLES9. It's simply not possible to build it since Gtk+ on SLES9 is so old that Firefox 3 refuses to build (and run). Nix (whatever this is) wouldn't help you in that case I guess.
Yes it would. You'd simply build and install the newer Gtk+, and then Firefox. Nix allows multiple versions of Gtk+ (or anything else) to exist at the same time, so installing the new Gtk+ doesn't mean uninstalling the old one.
I'm not arguing that we should all fall in love with Nix, but rather that it does solve at least one problem that is currently unsolved, and therefore (in the academic spirit) it's worth thinking about what it means, etc.
-Archie
Archie Cobbs napsal(a):
On Fri, Mar 6, 2009 at 12:55 PM, Wolfgang Rosenauer wolfgang@rosenauer.org wrote:
A little bit offtopic to the main but for your example. There is a reason there is no Firefox 3 for SLES9. It's simply not possible to build it since Gtk+ on SLES9 is so old that Firefox 3 refuses to build (and run). Nix (whatever this is) wouldn't help you in that case I guess.
Yes it would. You'd simply build and install the newer Gtk+, and then Firefox. Nix allows multiple versions of Gtk+ (or anything else) to exist at the same time, so installing the new Gtk+ doesn't mean uninstalling the old one.
RPM does also allow it (that the upper level tools usually don't is another story). And installing into versioned directories, which is AFAIU what Nix does, is more a matter of packaging policy than of the tools ("oh, I don't like having all libraries in /usr/lib, let's invent another package manager" -- ???).
Michal
On Fri, 2009-03-06 at 11:01 -0600, Archie Cobbs wrote:
On Fri, Mar 6, 2009 at 10:37 AM, Cristian Rodríguez crrodriguez@suse.de wrote: I ask because I've found myself in the situation described in the article: afraid to upgrade, because of past bad experiences and the knowledge that stuff I've built on my machine will break, and instead waiting for the next hard disk crash when I will have to reinstall anyway :-) On the other hand, I would be happy to hear that I'm being too pessimistic about the openSUSE upgrade process and why. How should one avoid dependency hell? Maybe I'm doing it all wrong.
The upgrade process has been pretty good to me (11.1 has been fabulous). I've been upgrading since 10.0.
A simple example: I have an old SLES9 machine. It still works great and I use it every day. However, when I tried upgrading my Firefox 2.x to 3.x, it quickly became impossible and I gave up (there is no pre-built Firefox 3.x for SLES9 in OBS).
I look at it this way: if you updated so many components to be able run run FF3 then you wouldn't, in any practical sense, have a SLES9 machine anymore. So do it the easy way and update to SLES 10, etc...
2009/3/6 Archie Cobbs archie@dellroad.org:
I thought folks on this list would be interested to read this article about Nix:
I would avoid the expression "dependency hell" since it's too vague and usually used by uninformed people. I would also avoid say thing like "All popular package managers, including APT, RPM", since people will ignore you if you are talking about package managing and you don't understand the difference between DPKG and APT (or RPM and ZYpp). Still, the idea is interesting. Even if I would need to look better, specially about this "cryptographic hash" that is supposed to look at anything that would create an incompatible package. Say Firefox depends on packages libA 2.14 and libB, and libB depends on libA 2.2. libA 2.14 is loaded first and even if libB is compiled against libA 2.2, at runtime the linker will resolve the symbols against libA 2.14... and Firefox crashes. Is the "cryptographic hash" smart enough to see these problems?
I'm also not very sure about how the software from NIX packages interacts with the "base distro" (but that would not be a problem is their own distro, NixOS). The FONTCONFIG_FILE thing doesn't sound good.
And anyway it has the usual problems. Do you really want to load three or four different copies of GTK in memory? Memory is finite.
If someday I see this "NixOS" in the top ten of Distrowatch I will try it. But I don't see anything the openSUSE project can or needs to do about this Nix package manager. A Nix package can be created (anyone is free to do so in the OBS) to make easier the installation... but after that Nix packaged software runs "separated" from the main distro, with even his own copy of libc. It's basically a different distro running over openSUSE.
Cristian Morales Vega escribió:
And anyway it has the usual problems. Do you really want to load three or four different copies of GTK in memory? Memory is finite. but after that Nix packaged software runs "separated" from the main distro, with even his own copy of libc. It's basically a different distro running over openSUSE.
Those two things immediately rules it out from my POV, in fact, we go in the opposite direction avoiding bundled libraries, static linking or any thing that can cause unneeded or duplicated work.
buildservice@lists.opensuse.org
-
Adam Tauno Williams -
Archie Cobbs -
Cristian Morales Vega -
Cristian Rodríguez -
Michal Marek -
Wolfgang Rosenauer