This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
From: Wayne Earl <wayne@qconcepts.net> To: svlug@svlug.org Subject: Re: [svlug] Comments on commercial distros On Wed, Oct 10, 2001 at 01:15:47AM -0700 or therabouts, Nate Campi wrote: > I've gotten to the point where I almost hate non-debian Linux distros. I > can't help but think how they've had apt (and dselect) to model their > package aquisition after for years, but haven't bothered. I spend so > much less time administering debian boxes it's pitiful. It allows me to > tweak my monitoring system or read to my son instead of track down where > to get some package, or fix broken dependencies. It all boils down to sysadmin style and operational needs; my experience is exactly the opposite. At work, all *nix servers are application servers (read: not multi-user). In this environment, I have found that Red Hat works best, because I stick to the following process: 1. All base system packages are rpms, installed from Red Hat's ftp servers or an appropriate mirror. 2. All application related packages are compiled from source tarballs. I find that the problem with apt is that it's TOO helpful, particularly with perl modules (the applications are mod_perl based). Also, we use about 30 perl modules from CPAN - only 13 of these exist as debs, and all of those are the wrong version. It is (IMO) a debian truism - if you compile anything from source, sooner or later, apt will hose the package. I've seen this dozens of times. Now, I could make debs, customize apt, build source debs for specific packages (I endlessly tweak apache/mod_perl/php4/glibc/mysql for performance, so all of the above must also come in source form). However, by the time I've completed all the above, I've done more work than if I just used rpms and compiled from source. Debian is just like FSF (and Microsoft, for that matter) - you either go all the way, or at some time in the future, it becomes painful. === Date: Wed, 10 Oct 2001 08:54:35 -0700 From: Will Lowe <harpo@thebackrow.net> To: Wayne Earl <wayne@qconcepts.net>, svlug@svlug.org Subject: Re: [svlug] Comments on commercial distros [ Yeah, I'm biased. ] > It is (IMO) a debian truism - if you compile anything from source, > sooner or later, apt will hose the package. I've seen this dozens of > times. It shouldn't, if you do things the Right(tm) way. apt and dpkg won't touch things in /usr/local or /opt, which is where locally-installed packages (including perl modules) Belong(tm), according to the FHS. Granted, there's no reason why an admin HAS to follow the FHS, but ... I've been running Debian for years and never had a problem, as long as I kept things out of the part of the filesystem Debian claims as its own. > Now, I could make debs, customize apt, build source debs for specific > packages (I endlessly tweak apache/mod_perl/php4/glibc/mysql for > performance, so all of the above must also come in source form). > However, by the time I've completed all the above, I've done more work > than if I just used rpms and compiled from source. How do you distribute the changes to each machine? I have the same sorts of problems, and ~50 debian boxes at work to keep those packages in sync on. I find it simplest to build ONE new .deb, put it in my local apt archive, and run apt-get on each machine ... as a matter of fact, I have a script (http://people.debian.org/~lowe/aptwatcher) that runs apt nightly and mails me if there are packages that need to be installed. In a large environment, I'd go nuts without some automatic system to warn me when new security packages have been released. I suppose I could accomplish the same thing on Redhat the way I did on Solaris, with rdist or rsync, but that somehow seems less clean. ===