Hi! I'd like to know what all of you think about the following idea.
There is an idea about installing software in a way that simplifies upgrading to newer versions without breaking the "links/dependencies" between the currently installed applications/libraries. The idea is basen on "Install in Separate Directories" technique (LFS book, ch 6.3.2.2). And I wonder how reliable/viable it is, and how stable the system would be where the method is applied. As written in the chapter mentioned, we have to install all the packages (the book seems to imply "all the packages besides toolchain and maybe a few other packages") in separate directories. 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). 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. 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. The second idea is to build glibc-2.4 and just install it "over" the existsing 2.3.6 removing the files come with 2.3.6. You know this way is the worst anybody can suggest :) The idea of the suggested method is to install glibc-2.4 into /usr/pkg/glibc/2.4 and to build the "problem" package to use /usr/pkg/glibc/2.4/lib/ld-linux.so.2 for synamic linking. If I use this method, all the packages already linked against glibc-2.3.6 needn't to be rebuilt and they should work properly because glibc-2.3.6 is still in the system and they use it rather then newer glibc-2.4. When I need an application not able to be built with gcc4, I will install gcc-3.4.6 in /usr/pkg/gcc/3.4.6 and use it for compiling the package. Now, the questions: 1. Is the suggested method can work at all? I've heard programs compiled with gcc3 cannot be linked against libraries built using gcc4.1, and vice versa. It seems the same is with glibc 2.3/2.4. 2. If it would work, can I somehow simplify the process of searching dynamic/static libraries by ld/ld-linux. Using this idea I should add _every_ library package path to /etc/ld.so.conf so it will become huge a few months later. Setting $PATH, $LD_LIBRARY_PATH, $MANPATH gives rise to the same problem. I could create links /usr/lib/FILE to /usr/pkg/PACKAGE/lib/FILE but wouldn't such a huge number of links make the system slower? Besides, I won't be able to create /lib/ld-linux.so.2 symlink because it cannot point to _both_ glibc-2.3.6 and glibc-2.4 so I'll have do decide what glibc should be "the default". 3. Would such a system be "unstable" because of some packages being linked against (for example) glibc-2.3 while others being linked against glibc-2.4 end so on? 4. Is the idea described here described somewhere else? I tried google but found nothing essential. I'll be happy to hear your opinion about the subject. -- Nothing but perfection pv -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
