On Sunday 17 September 2006 03:00, Ken Moffat wrote: > 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.
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. Though, if using scripts you mentioned I can do something else while rebuilding the system and that's good. 2. I prefer to use not only the "default" options while building a package. For example, I've built gawk with --enable-switch option. What's important is that I still need to look through package's configure script to find the options I can use. So, I cannot just "build a new system with the latest versions of everything" since the options can be changed with the new release. > 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 this case, the suggested method is exactly the same, the only difference being the directory where the new package goes to. > > 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. > So, are you trying to find possible problems for your new method, > or do you have current problems ? 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. 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... 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. > > 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. P.S. It's probably my problem that I don't like the need to look for patches in other distros :( -- 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
