On 9/16/06, Vladimir A. Pavlov <[EMAIL PROTECTED]> wrote:
Let's assume we installed _all_ the packages into separate subdirectories of /usr/pkg (the packages needed for boot should be placed to /pkg, while ones not needed should go to /usr/pkg. To simplify the description, we install all of them to /usr/pkg).
You asked for opinions, so here's mine. I think this is a dead end approach that is overly complex. Let's assume that you can get all the toolchain components pointed where you want through some combination of LD_LIBRARY_PATH, PATH, /etc/ld.so.conf, etc. That is only one part of the story. Many programs hard code locations and expect to see other tools/libs/data in standard locations. Even with symlinks, it's a lot of work. IMO, it's much preferred to just get a decent package manager and install to the standard locations. But, in a later email it seems you really want to have multiple versions available. In that case, I suppose they really need to be in their own roots. More on this later.
Let's also assume we installed gcc-4.1.1 and glibc-2.3.6. into /usr/pkg/gcc/4.1.1 and /usr/pkg/glibc/2.3.6 accordingly and all the packages use /usr/pkg/glibc/2.3.6/lib/ld-linux.so.2 for dynamic linking. Now I have a package that cannot be compiled with glibc-2.3.6 since it requires glibc-2.4.
Hmm, that seems kind of sketchy. I would not install multiple versions of glibc. It's a special package that provides tools that are on the same level as the kernel in my mind. The dynamic linker and the libc are probably not things where you'd want to have multiple versions trying to work at once. I would expect some odd things to happen. Further, the glibc maintainers work hard to make sure it is backwards compatible. So, upgrading to glibc-2.4 and running binaries that were linked against glibc-2.3.x should be fine. On the other hand, binaries linked against glibc-2.4 are a lot less likely to work in a glibc-2.3.x based system. You can't really make a program forward compatible.
The first idea in my head is to rebuild _whole_ LFS to use glibc-2.4 but I don't like it because 1) I have no time to do it, 2) some packages cannot be linked against glibc-2.4.
I think Ken's suggestion about having multiple systems is much more realistic. Aside from glibc, though, something you might want to check out is unionfs. There have been a lot of ideas kicked around about using this as part of a package management scheme. I don't know if there are any fully developed versions yet. With unionfs, you can overlay all the package directories right into /. So, then you could change which version of the package was currently merged into / without having to ditch all the standard prefix conventions. http://www.am-utils.org/project-unionfs.html -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
