[As The Linux Lobbyist comes to life, he says...] Oh, goody, my favorite flamewar! ;-)
On Thu, 2005-02-10 at 01:09 -0500, Jason Stephenson wrote: > Heh..... I find this discussion mildly interesting from where I sit, a > mostly xBSD user. As preface, let me say that I like the BSDs somewhat, save the anti- GPL bigotry among many of the developers that is usually accompanied by a completely lack of understanding (or deliberate misrepresentation) of its terms. [snip] > we had multiple systems running HP-UX, > Solaris, IRIX, Red Hat GNU/Linux, Debian GNU/Linux, FreeBSD, and even 1 Hmm, "Red Hat GNU/Linux"? Is that something new that Red Hat is selling and/or distributing? Because I've never heard of it before. Funny...poking around http://www.redhat.com/, it looks like Red Hat has heard of it either! So I guess I'm not crazy. Okay, putting the sarcasm aside, I have no problem with referring to Red Hat Enterprise Linux as well as Fedora Core as "GNU/Linux based operating systems." But as far as I'm concerned, when you put the distribution together, you get to keep the naming rights. Not the FSF. Not the GNU project. And not (sorry, I know he may be on this list, but that's life) Richard Stallman. For the record, I like and agree with nearly everything, if not everything that has come from those three. And if RMS and I hashed this particular issue out over a latte we'd probably end up agreeing in the end. > It was largely the issues of "package management" that made me decide to > go with FreeBSD and OpenBSD for my computers at home, instead of various > flavors of GNU/Linux. I found the ports collections to be the solution > to deb and rpm hells. In almost every case, I cd into the program's > ports directory, type 'make install' and the software builds, installs, > and then runs with no hitches. There's very little to package manage and > that's how it should be, IMHO. Ah, but you are demonstrating almost the exact disconnect that Ben spoke about in his initial complaint about how the Debianites equate the large collection of debs available at many mirrors with the functionality of apt-get when apt-get is not at all unique and arguably inferior to many of the equivalent dependency resolution tools available in rpmland. What's missing in the GNU/Linux world (there, see? I'm not totally opposed to "GNU/Linux" usage ;-)) outside of Debian is a good process. (Debian, of course, could use a little *less* process so that there is an update more than once a decade.) The tools are really there with possibly some minor tweaks necessary. What the BSD ports collection seems to have is an excellent process for making sure that everything works together. I don't know how big the ports collections are in the various BSDs, but its possible that there is also more software than you will find in the typical GNU/Linux distro (save Debian, of course). > I experienced all kinds of problems on the Linux machines, mainly > because we were a research institution and the profs would need some > bizarre hardware combination that wouldn't quite work with the default > packages from the various releases. It became a nightmare trying to > maintain a machine loading packages from 2 different Debian releases, or > trying to install binary RPMs on some of the RedHat machines with > different kernels, etc. Wait, I'm have a little trouble understanding the problem. What were the problems specifically? If you are saying that you needed to install a custom kernel and because you did that (with make bzImage;make modules;make install;make modules_install or whatever), then I think I see the problem. It all comes down to packaging. I'm a packaging fanatic. I hate stuff in /usr/local. I also won't touch a 'make install' as root with a ten foot pole that poops all over my filesystem. I create rpms in my sleep even. If I were a Slackware fan, I'd create tgz's in my sleep. The point is, an OS should be divided up into manageable chunks so that they can be updated independently and without source. Source is good, but how many times, for example, do you want to build perl and answer those questions? So, I've even going as far as foregoing the (rather baroque, IMO) usually kernel compile/install. Instead, I start with Red Hat's source rpm file and make the mods there. Add a tag to the Release: to indicate it's changed and 'rpmbuild -bs SPECS/kernel-2.6.spec;rpmbuild --rebuild --target=i586,i686,noarch SRPMS/kernel-<version>-<release>.src.rpm' and a while latter I have some binary kernel rpms that keeps the dependency tree in /var/lib/rpm consistent. It's work, yes, but once you master it, it's *much* easier to diagnose many classes of problems. You master the OSes you need to deal with. What I'm saying is that your choice to go with BSDs in some places was very likely the right one for you, particularly if you had more of an interest in learning them because that inertia alone would help you in managing those machines. > It soon became routine for my colleague and I to install nearly > everything from source code on certain machines because we knew that the > packages would not work. Again, the problem was probably one not having anything to do with the principles behind using binary rpms. > I can't count the number of times I've had > > apt-get update > apt-get install > > fail and for what reasons when. > > I've also dealt with RPM-hell of having to install RPM after RPM, just > to get the one thing that I want to use installed. I've also had > installs fail on some machine, again because of custom packages needed > for one reason or another. The problem is not the tool, but how it is being used. Either by you or the packager(s). More likely it's the latter. So called RPM-hell is a myth. Before I get flamed for that, let me explain. When rpm bitches about dependencies, it is doing *exactly* what it was designed to do. If I were a betting man I would wager that a good 70-90% of the so-called rpm-hell problems have direct cause related to the admin of the machine doing several of the following commands over time: rpm -ivh --force <package.rpm> rpm -ivh --nodeps <package.rpm> ./configure;make;make install The remainder of the problems either have to do with a) mixing repositories that have explicit warnings about mixing with certain other repositories b) grabbing random rpms from joeblow.com and installing them without doing any kind of due diligence checks, c) using rpm barebones instead of the provided depsolving tools (yum, apt-rpm, urpmi), or d) genuine packaging problems that the packager needs to fix. And maybe less than 1% are real bugs in rpm or any kind of problem with philosophy behind rpm. > I can tell you that I've only ever had two package fail make install in > FreeBSD ports because one time I updated right after a change to one > package, and the second time because the package maintainer had written > his makefile to check for the headers from a specific version of the > mysql libs and I'd installed a more recent one. In both cases, the fixes > were simple changes to the makefile that I sent off to the package > maintainers. One was incorporated into the makefile, and the other > maintainer wrote back thanking me, but that he'd already updated the > repository with a "better" change. And those kinds of problems happen with rpms, too, but can be addressed nearly identically: contact the packager or grab the source rpm and fix it yourself if it's not too complex. Again, it's about mastering the OSes that you have to deal with. That's assuming, of course, that the OS gives you the tools to accomplish the task. The rpm and depsolver suites of tools certainly provide those capabilities in the vast majority of the cases. [snip] > Oh, and don't get me started on the "package management" in IRIX, HP-UX, > and Solaris. They have varying degrees of success and failure, and you > often have to go to third party sources on the Internet or resort to > installing things from source for the useful stuff. Hehe. There, I can agree 100%. :-) > Anyway, to me, it isn't software without source code, and I do prefer to > install from source because then you know it works with the libraries > installed on your system because it was compiled against those very > libraries. You don't need to worry about binary compatibility issues > between different library and kernel versions busting your binary > packages. Yeah, you could end up with something that doesn't compile, > but at least then, you can see what the problem is and fix it yourself. True, but you also may loose all record of your fix if you forget which source tree is which. It's much easier to backup a single source rpm that has your patch and comments recorded in the spec file. I also find this discussion somewhat interesting because there have been at least a few recent threads on the fedora-devel and fedora-test lists about depsolver tools. The developer of yum (Seth Vidal) is on those lists and though he is quite understandably biased toward yum, he is always willing to engage in conversations about ways to do it better. My personal take is that at least the majority of participants in those discussions are not adamant about one depsovler or another, but just want whatever is chosen as the default to do-the-right-thing- dammit, which is my position. On the Red Hat (rpm) vs. Debian (dpkg) debate: I posed a challenge some time ago on this list for anyone familiar with deb package internals and/or dep packaging building to list, point by point why dpkg was superior to rpm. The condition was that apt-get be left out of the discussion completely. My reason was the same as Ben's: it's apples an oranges. You wan't to compare yum vs. apt-get vs. smartpm vs. urpmi? Fine. But that's all moot now that apt4rpm exists, isn't it? Nobody took the challenge. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss