Forum Moderators: bakedjake
Another issue is what I refer to as 'dependency escalation'. In the beginning you upgrade a package by simply downloading the upgraded version and installing it. You only installed one package, so most of the time you only need to test a single application. A couple of months later, that package cannot be upgraded anymore without first upgrading its dependencies (the packages it depends on; most likely libraries). Upgrading the dependencies requires a lot more testing because you need to test all your other installed applications relying on these dependencies. As the months go by, you can't upgrade a package without spending a day or two upgrading its dependencies one by one and testing their effect on the whole system.
In the end, you will refrain from keeping your system upgraded. You'll have to live with existing bugs, you'll have to leave newly discovered security leaks unfixed and you can't add new features to the system. You're only option is to start over by installing a new distribution and migrating all your existing applications. The cycle repeats itself ...
I can currently only think of one solution: one server per application. That way you won't have to worry about cross dependencies when upgrading packages and their dependencies and you can even update the whole distribution without fearing it might break your other applications. But this can only be an option for medium and big businesses and they most likely do it anyway in order to balance the load on their machines. For smaller businesses, VMWare ESX might be an option, multiple virtual servers on one physical server and one virtual server per application.
Proper management of libraries should fix the problem. By convention, libraries with the same major version are binary-compatible, and it is possible to have multiple major versions of the same library co-exist on the same box.
I've stuck with Red Hat (and now Fedora in most instances) for the past several years, and follow the update tree (first with scripts, then up2date, and now yum). If a package does not exist in the distribution, I build an RPM for it (or use an .srpm that already exists). I try to rebuild 3rd party rpms for my own box for some of the reasons you specified, namely to make sure they're linked against the major version of the libraries I have on my system, and that the dependencies are properly recorded in my RPM database (since some distros break out packages differently).
In the event you do need to track a source tree, having an .srpm makes maintenance much easier since it's one command to rebuild it exactly like you did before (ie with all the same ./configure options), plus you get file/version tracking.
The only time I've run into some of the problems like you mention are with X applications, since some of the GNOME components change major versions faster than I can count. That's where keeping multiple versions on the same system is important.
Sean
Updating a package is accomplished via: "emerge sync; emerge -u world"
Updating configuration files (where necessary) is done via "etc-update", which spits out a diff comparison and prompts the user between keeping the original, updated, or line by line concatenation of both.
Installation of 99% of what programs I use is done via: "emerge packagename" (somewhat similar to debians apt-get).
GlibC in your example does not prove an exception to the update methodology, the only one that I can think of that requires manual intervention is python (which requires "python-updater" command to be issued after updating), but there are a handful like this; packages such as this will beep a few times and give the user instructions via the terminal.
I love gentoos update system - but I have noticed that one needs to watch what is updated (apache moved from 1.x to 2.x some time ago for example) - hence two machines (I can update one on monday, and sit on it for a few days to ensure nothings borked with the knowledge that if it is borked I use the second machine and fix bork-ed-ness at my leasire).
I've stuck with Red Hat (and now Fedora in most instances) for the past several years, and follow the update tree
Does this mean that upgraded your Core 1 installation to Core 2 without reinstalling the whole distro?
Regarding SRPMs: I have always had the feeling that they are becoming more and more popular. In the past I had more problems installing binary RPMs than I had with compiling and installing packages myself. I think this mostly because autoconf makes the build process so convenient and standardized.
nalin,
I use a pair of servers running gentoo linux
Is one of them a backup server or do they both provide different services independently from each other?
I love gentoos update system - but I have noticed that one needs to watch what is updated (apache moved from 1.x to 2.x some time ago for example)
I guess if this happened to me, most of my web applications would break immediately. Is there a way to check what would happen during an upgrade, before the upgrade is actually started? I mean some sort of dry-run or what-if option?
I browsed the Gentoo and Fedora website and I will install them on a test machine. I'm really bored with the mainstream distro's. I tried Suse, Redhat and Debian. I think it's time for a change.
Does this mean that upgraded your Core 1 installation to Core 2 without reinstalling the whole distro?
I haven't done that one in particular, but I've gone from RH9 to FC2, and various RH{7.3,8,9}->FC1 migrations without reinstalling. In fact, I do it hot, ie the only reboot is the one to bring up the new kernel.
Sean
Is there a way to check what would happen during an upgrade, before the upgrade is actually started? I mean some sort of dry-run or what-if option?
I've recently switched from Red Hat 9 to Gentoo and I'm very glad that I did. :)
No more dependency trouble. Gentoo will automatically download and install any package's dependencies. ;)
I use a pair of servers running gentoo linux
Is one of them a backup server or do they both provide different services independently from each other?
I've recently switched from Red Hat 9 to Gentoo and I'm very glad that I did.
I've checked out the various distros over the last few years, heard about gentoo, saw the emerge feature in action after having redhat rpm failures to upgrade something as basic as mozilla/firefox, and think that would be the one for me to use, mainly because of these kinds of updating issues, but when I check out the installation directions on their website it's pretty intimidating, is there an easier way to install it? And is it safe to install in a multiboot environment (there's just too many windows apps I need access to)? Or should it ideally be on its own machine?
Any thoughts on this would be appreciated, thanks.
...when I check out the installation directions on their website it's pretty intimidating, is there an easier way to install it?
Part of the reason I enjoy gentoo is that I went from a several year on-again off-agin redhat deal to feeling like I knew my system and could handle linux in all of about about 24 hours, there is something empowering about the installation that serves almost as a right of passage for the gentoo user.
is it safe to install in a multiboot environment
We also have one web server running Debian and I haven't had any problems with apt-get yet. Works like a charm!
Slackware, as someone already suggested, is another fine Linux distro, fast as **** (was faster than Gentoo on the same hardware) and their package management (just good ole tgz stuff) is quite hazzle-free. It's quite difficult to find a dedicated server provider that offers Slackware, though.
Fedora etc. may be ok, but I have to admit that after using apt-get or FreeBSD's ports I just cannot imagine going back to a RPM based distro. Maybe things have improved, but bad memories are still haunting me at night <G>
