On Sun, Sep 17, 2006 at 10:23:55PM +0400, Vladimir A. Pavlov wrote: > The bad things for me are: > > 1. Rebuilding a whole system (including BLFS) requires too much time. > Adding one really needed library is much faster. > Sure. I'm trying to point out that you can easily spend more time than this developing your own package-management tools and ironing out the problems. When I started scripting, I used an excessively complex method, and wasted a lot of time. It's your time, so I don't really care how you spend it ;)
> > > 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. > > It's my guess about _binary_ compatibility. As I said before, > rebuilding a whole system is rather expensive in terms of the time > required. > Well, my guess is that trying to use more than one version of glibc will cause you a lot of pain. > The main goals of the method are: > > 1. Having a possibility to have several concurrect versions of a > package. This's important for me as I'm a developer. I'd like to > test whether a program can be compiled with gcc-SVN but I don't > want to build my whole system with a SVN compiler. "I'm a developer" - _what_ are you developing ? the phrase means many different things. If you are developing your own distro, you don't normally want multiple versions of things, having 'stable' and 'unstable' is usually bad enough. If you are developing a particular package, yes, you might want to test it against multiple systems (but then, testing against e.g. current fedora and debian unstable is perhaps more useful for your users). Nobody can test against everything and you will always be subject to the problems caused in a particular distro by a random update. > > 2. Having a possibility to quickly add a new version of a package > without full rebuilding. Not to replace the old version with the > new one, but to add the new version so that the old one remains in > the system. > > 3. Doing 1. and 2. for _every_ package in a _similar_ way. > > Well, I guess this "_every_" confuses you, but I don't know what > package I will have/want to upgrade tomorrow... Your bigger problem is probably managing the multiple versions - even with a single version of glibc and a single version of gcc you can still have many different combinations of different versions (taking your example that follows - say two versions each of apache, php, mysql - I make that eight combinations just for a simple lamp stack - now add alternate versions of another three basic tools and you have 64 different combinations). > Now I need multiple versions of gcc, php, apache, mysql. I would > also like to try binutils-2.17 and glibc-2.4 but I don't want to > switch the whole system to them. > I admire the breadth of your reach! Seriously, I think you will find the overall problem more manageable with a series of different systems. As I said, geniuses can handle complexity, I can't. On the other hand, if you really want to concentrate on developing a package management system, don't let me discourage you. > P.S. It's probably my problem that I don't like the need to look for > patches in other distros :( Yes, it is. The whole point of free software is that if somebody fixes a problem, we don't all have to work out the details on our own. I'm not saying that you should accept _any_ patches without reviewing them, but looking to see what other people have already done is an efficient way of solving problems. 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
