On Sat, Sep 16, 2006 at 11:01:07PM +0400, Vladimir A. Pavlov wrote: > Hi! > > I'd like to know what all of you think about the following idea. > As somebody who only barely uses package management (I keep a note of what gets installed), and who typically rebuilds his desktop systems every few months, I think it sounds horrendously complicated! Geniuses can handle complicated, for the rest of us it leads to more errors. Also, you will probably get to deal with new and exotic failure modes :)
> 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). > What is so bad about scripting your builds, and then building a new system with the latest versions of everything ? Yes, it means having at least two potential '/' filesystems, and probably a separate /home, but it's no big deal and means you can fall back to the "recent, working" system if the latest one gives problems. Also, you need to be clear about _why_ you are upgrading a package. For BLFS, particularly for desktops, upgrading is a frequent event and can often be handled by building in /opt/kde-3.5.4 or ~/gnome-2.16 while keeping an earlier version somewhere else. For the basic LFS system itself, most packages do not show any obvious benefit from upgrading (apart from security problems, obviously). If you just want to test the latest desktop stuff, keeping it separate from what is known to work is usually a good idea. > Now I have a package that cannot be compiled with glibc-2.3.6 since it > requires glibc-2.4. Is this real, or a made up example ? Any _source_ that needs a specific version of glibc is at least unusual. > > 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. Examples ? I know compiling strace broke with 2.4, but the fix was already in their CVS and has now been released for several months. I'm sure it's more likely with binaries, but for an LFS user any reliance on binaries is surely an exception to the normal "build it from source" method. > 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. Again, this seems unlikely. There are a few unmaintained packages which might need old versions of gcc (maybe gtk+-1.2 or mpg123, I wouldn't know) but most people can get rid of those. Anything current has probably already been patched - check in fedora or gentoo. More likely, binary packages (in my case, realplayer) need the old version of libstdc++ - that means gcc-3.3, not 3.4, and is already covered in the BLFS book. In any case, having multiple versions of gcc is not a big deal, it's only multiple versions of glibc that are going to be painful. So, are you trying to find possible problems for your new method, or do you have current problems ? A professor will tell you that exploring possible problems that might happen is a good idea, but practical people will suggest you should only care about what is likely to happen - going off on your own path may well be intellectually interesting and educational for you, but it will use a lot of your available time. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
