On Sat, Mar 26, 2011 at 1:53 PM, Keith Lofstrom <kei...@kl-ic.com> wrote: >> On Mar 26, 2011 11:13 AM, "Keith Lofstrom" <kei...@kl-ic.com> wrote: > ... using multiple library versions simultaneously > > On Sat, Mar 26, 2011 at 01:04:59PM -0700, Rogan Creswick wrote: >> NixOs does much of what you describe, retaining multiple versions of a >> library, but I have not yet tried it. > > If I understand their webpage, NixOs retains previous libraries, > enforcing compatability through compilation, but the previous > libraries are not simultaneously usable. It seems more like > GenToo, which rebuilds everything from source (AFAIKS).
The NixOS package manager, Nix (which is separable from the OS), does claim to support this. Albiet, you *do* need to package the application for Nix. Such is often the case when you want more capabilities, and if I can jump ahead a bit: determining and managing the dependencies for a given application is devilishly hard (even if you know all the valid version ranges, and all the version number changes actually correspond to some sensible semantics, the general case is NP-Complete. If the semantics of the applications aren't accurately represented by the version numbers it become uncomputable.) >From the Nix page: "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." > NixOs appears to enforce One Giant Compatability. You must have > the source for every component, and those components must all be > compatably written. Besides make files and dependency lists, > there must also be an accurate Nix language description of those > dependencies. NixOs looks like a great way to build small, > secure, and robust systems, and to test new configurations and > roll back to old ones. But for big shambling collections of > thousands of applications from thousands of sources, such as > the typical desktop system, that seems impractical. I am also quite concerned about that -- and why I'm not (intentionally) preaching in favor of NixOS. There is a very good chance it has insufficient package support. I'm hoping to try an install in a few weeks to see how the process goes. If it's relatively easy to create nix packages, then I'll likely use it, but I'm somewhat uniquely motivated. (Much of my recent work has been on build systems, setting up continuous integration, and sandboxing -- three things that Nix should help with enormously.) > In my case, even harder. I write about 100 programs a year, > little one-offs that do some bit of numerical calculation for > something I am designing (my computer - computes! Fancy that!!). > I would either do those outside of Nix (and risk them failing > if I tried using the binaries later), or I spend a lot of extra > effort describing their dependencies. We're feeling a lot of the same pain, I think. I can suggest a solution for Haskell (cabal-dev), but I suspect that won't help you. Building static binaries is the best solution I'm aware of at the moment, and clearly not an option at all for many, many things. > Real systems connect to other systems, and the dependencies > spill across machine boundaries. Sometimes you need to run > program version A to connect to machine A, and program version B > to connect to B. That happens with Perl. Our friends at Redhat > have their own /usr/bin/perl, which is an old and strangely > patched version that is incompatible with most new stuff Out > There, but essential for their system tools to work. So, we > also end up building /usr/local/bin/perl, keeping that upgraded, > and using that for everything besides system supplied stuff. > It would be nice to have a less kludgy way to do such things, > and less work than rewriting everything for rigid compatability. There are things in the works that should help with this sort of thing (locally, by Pluggers even! :) * http://corp.galois.com/blog/2010/9/30/tech-talk-enabling-portable-build-systems.html My apologies for the relatively low-content nature of that link -- I should see about doing another talk. --Rogan > NixOs does not appear to have any mechanism for supporting > multiple versions of libraries simultaneously, and in fact > would make the "two-Perl" solution more difficult. While it > would be nice to get everyone to write code that would play > together nicely, the history of a half century of software > production suggests this is unlikely. > > Is there something I don't understand here? I don't run > GenToo, so perhaps recompiling and upgrading from source, and > determining the dependencies of applications, is not very hard. > > We build diverse systems. Rather than wait for some miraculous > convergence on universally compatible code, perhaps it is time > to design for that diversity. > > Keith > > -- > Keith Lofstrom kei...@keithl.com Voice (503)-520-1993 > KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" > Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs > _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
