Isaac Dupree wrote: > I don't want to lose versioning for them totally. (inventing things)
Now I remember what sort of thing I was concerned about... [er, looks like Hisham has already analyzed it quite well. You may skip to the "other considerations" section if you wish] I think this is similar for Python (.pyc), Haskell/GHC ... I'll discuss what I know. For stable languages/implementations that always use interpretation from source, upgrading them may not matter. Suppose you installed GHC 6.4 and a bunch of libraries. They are compiled and work with only GHC version 6.4. Then you install GHC version 6.6 and symlink it. Of course the existing installed Haskell libraries don't work with it - they would at least have to be recompiled. You install some libraries using GHC 6.6. Then you decide to use GHC 6.4 again. You symlink it (or ideally would be able to use /System/Links/Executables/ghc-6.4 without needing to symlink it), and expect to be able to use those libraries that you had installed back before GHC 6.6 was even released. Eventually you go back to GHC 6.6 and decide to purge your system of all that 6.4 junk. You want to delete the GHC-6.4 alien set. **** Some other considerations: It would be nice when upgrading GHC to be able to automatically recompile the same set of libraries that were already installed. Either it's easy to make a script that can do this, or it isn't, so I'm not worried about that. Some libraries, like 'base' are very entwined with GHC internals currently, and each version of them goes with a particular GHC version - other libraries can have incompatibilities too - automatic upgrading or staying the same is probably never going to be perfect -- if it had to be, we would be waiting months for new compiler versions, somewhat like how it is in Gentoo! As a developer I may prefer an unperfected new version. Although that in itself raises a good point - if I'm not a developer, some program I'm installing depends on a library that turns out to require a newer version of GHC, hopefully this will fail gracefully (it's probably asking too much to automatically upgrade GHC at that point). We need to be careful about where ghc-pkg database is (it's probably part of GHC's `make install`) and where the libraries it installs, go. We obviously don't want them ending up inside /Programs/GHC or /System/Links. GHC releases come with varying amounts of pre-installed libraries, too (at minimum, enough to compile another version of GHC, and more for the official linux-x86 binary packages). More than one GHC-6.6 can be installed in Gobo (I have GHC-Bin 6.6.1 and GHC 6.6.1) (libraries they compile/contain should be compatible with--equivalent to-- each other). I wonder if we can/should get these libraries to be put in /System/Aliens along with haskell libraries installed later. Isaac _______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
