An experiment in collective intelligence. Stupidity. Whatever.
| TWikIWeThey . Main . WhyDebianRocks |
TWikIWeThey webs: Main | TWiki | Know | Test |
| Main . { Welcome | Topics | FAQ | Changes | Index | Search | Go } |
apt-get install foo, you're not just installing software. You're enforcing policy - and that policy's objective is to give you the best possible system.
What Policy defines are the bounds of Debian, not your own actions on the system. Policy states what parts of the system the package management system can change, and what it can't, how to handle configuration files, etc. By limiting the scope of the distribution in this way, it's possible for the system administrator to make modifications outside the area without fear that Debian packages will affect these changes. In essence, Policy introduces a new class of bugs, policy bugs. Policy bugs are release-critical -- a package which violates policy will not be included in the official stable Debian release.
Let me reiterate, because that is the whole secret: A package which violates policy will not be included in the official stable Debian release.
deborphan and orphaner can exist - this program finds libraries that nothing depends on. Because nothing depends on them, they can be safely removed.
Another feature of Debian is that it has a lot of software. An awful lot. At the last count, there were over 12,000 software packages in the "unstable" branch of the Debian system. This is far more software than is available for any other Free operating system, by some margin.
apt-get update && echo y | apt-get dist-upgrade, though in practice, trusting updates to this extent isn't quite recommended. The process, for a typical nightly update, depends on your download speed, as updates tend to range between tens to hundreds of MiB. The installation phase itself usually completes in a matter of minutes.
A more conservative practice is to run a nightly update, but run dist-upgrade in download-only mode, allowing you to manually inspect packages to be updated, and committing them when you're satisfied all is well.
Your cron job (in /etc/cron.daily/apt-get) looks like:
#!/bin/sh # /etc/cron.daily/apt-get # Written by Karsten M. Self # Tue Feb 12 22:54:22 PST 2002 # Run an update on apt archives and download latest updates (but don't # install), daily. PATH=/sbin:/bin:/usr/sbin:/usr/bin echo -e "\nFetching list updates:" apt-get update echo -e "\nFetching package updates:" echo y | apt-get -d dist-upgrade # tidy up the archives echo -e "\nFree space on /var, before autoclean:" df /var apt-get autoclean echo -e "\nFree space on /var, after autoclean:" df /var
rsh packages. telnet (and telnetd) aren't installed by default)
dselect . Now, one of the reasons that the installer doesn't get as much attention in Debian as it might do in, say, MandrakeLinux? or RedHatLinux is that people tend to install Debian much less often, because upgrading works. (There is a disturbing tendency for some deranged souls to install some horrendously old version of Debian, and then to upgrade it directly to the latest. Just because they can. OK, so some people need to get out more. But it's worth pointing out that Debian maintained compatibility across the libc5->libc6 transition, while Red Hat did not ( 
or So says Karsten. It appears to me this is a RedHerring? issue, as we all know that the packages compat-libc5, compat-glibc and the like address this exact issue which were in the installation, although NOT by default 
-- GregFolkert - 24 Sep 2002) - this probably accounted for an awful lot of reinstalls of Red Hat and friends.
However, the current Debian installation program is much improved. Yes, it's text based (the GUI-dependent may take heart that Progeny's graphical installer is being discussed for upcoming release(s)) (and is available for daring souls at http://archive.progeny.com/progeny/pgi/ ). This means that you can get something installed and you don't have to worry about having a working X installation (if things are going to go wrong in a Linux installation this is usually the scene of the accident). Once the base system is on, a simple "apt-get install x-window-system" will get you cooking on gas.
The real meat of the installer is the fact that although there is a suggested course of action, you are free to go back and change stuff - within reason, of course - and then resume where you left off. Unlike some GNU/Linux installers, Debian comes with a functional installation environment, including bash and a healthy selection of shell tools. If it's necessary to go in and muck with things by hand during the install, or if you need a rescue system, you've got one.
apt-get and aptitude or synaptic in particular will make package selection far simpler. If you've installed Debian before, you probably have a list of packages you like on a typical install. For the newbie, experience is that the first few days with a new system are typically spent exploring and installing additional packages. Dependency resolution means that if there are prerequisites for a package, they area selected and installed (after notifying the user of this) along with the requested package.
The result is a system that's typically far leaner, and more coherent, than an RPM-based distribution.
It might point out something that is probably not entirely obvious by the preceding paragraphs: Do not expect during a Debian CD install to say "Install Everything" and to walk away for 20 minutes. Whilst there are ways to achieve pretty much the same effect as a kitchen-sink RedHat install, the Debian system is practically designed to not need and not ever support this in a literal sense. Instead, be frugal and install only what you know you need. Debian's dependency system will add what is missing. Resist the temptation to install more than you need. Revel in installing (and removing) packages you want to investigate as you need them. Learn to love cruft, deborphan, orphaner, or if you want the thermonuclear system-cleaning tool, debfoster.
If you are looking for unattended installs, you want to look at FAI, the FullyAutomatedInstaller?. Available as a DebianPackage:fai.
/etc/init.d, /etc/rc[0-6S].d, vs. /etc/rc.d/*
Mainly, what are the main differences between say RedHat and Debian?This testimonial (at Deja) is pretty comprehensive. Most significant single difference: Debian Policy, which spells out what Debian does and doesn't include, where things go, and how they are administered. This gives Debian an overall integrity and stability which are unmatched in the Linux arena. The BSDs approach it, but from another direction.
Other than the obvious ones like apt vs. rpm. Directory structure? Anything else?Yes.
apt and rpm are significantly different. Not that apt is hard to use -- apt-get install foo and apt-get remove foo are pretty much most of what you need, day-to-day. There are a number of different tools for working with the packaging system, you'll want to be familiar with deselect (individual package management), apt-get (distribution management), apt-cache (package searching), and aptitude (graphical front-end to most of the above). apt is far more graceful and robust than RPM in my experience, particularly when dealing with partial or failed package installations and removal. Debian doesn't check GPG signatures by default, however, a full MD5 checksum database is provided, with the debsums utility to work with it.
I'm also minded by RickMoen, that:
Other significant differences:dpkgcan be configured to check gpg signatures of all packages against the contents ofdebian-keyring, and refuse to install all packages that fail the check. All you need do, to enable this feature, is install packagedebsigs.
pppconfig and Red Hat's printtool should get your dialup and printing configured. Everything else is relatively clean.
/etc/alternatives is where the question of "which vi is vi", etc., are resolved. You use the utility update-alternatives to modify these. There are a set of related tools for similar configurations.
/usr/share/doc, packages are represented by name, rather than name+version. This makes it far easier to refer, say, to bash documentation without needing to know the specific version installed.
Does Debian have a Pentium-optimized version?No, not in the sense of a full install built to a specific x86 architecture. You can compile from sources, and this is pretty straightforward, but the benefits are small. See Re: How to make all build using --cpu=pentium? and DebianAptSrc for details. Also, over time, debs for packages which do significantly benefit from 586, 685, K5, and K6 optimizations (eg: openssl, gnupg) are being built in optimized versions.
How much difficulty have you had with RedHat-oriented commercial software? Software in general?Specifically, none. I haven't installed a hell of a lot of stuff -- RealPlayer, a few versions of Netscape. In general, using
alien the fallback mode for Debian is that you're no worse (well, not much) off than using RedHat. OK, there's a Debian package for RealPlayer. Ditto Netscape, but that's pretty much obsolete these days. There are also Free Software alternatives to RealPlayer, notably Totem and GStreamer.
From elsewhere on the Web:
I have talked to a number of other software vendors who simply say, "We only support Red Hat". I know for a fact that most of these barely know what Linux is. My favorite is RH 6.1, which didn't bother installing support for parallel printer ports. Once you found there was a problem with the distribution (probably after installing several times), you had to track down the info on the Internet and edit configuration files by hand. I don't have time for this sort of crap and I don't know many people who do (fortunately I heard about it long before I had to deal with it). All this is exemplified by Mr. Young's answer to criticism of Red Hat 7.0: "Anybody seeking to do serious work with any software ought to test it thoroughly first anyway". Personally, I think a vendor who is charging for a product should do the testing. There is no sense in thousands of purchasers all doing the same testing on their own. That simply is not efficient use of time.
The Real Problem With Debian is that it is MANUAL. Everything must be done manually, now although there may be a script or two to ease things along, these often DON'T WORK. I have spent two weeks fighting SlackWare?, trying to get it to work with my printer, and sound card. Then I spent two weeks fighting Debian, trying to get it to work with my mouse, printer, network card, and sound card. After installing Mandrake, everything worked instantaneously, sound, card, network, printer, EVERYTHING. It ran faster too, I don't know why, but it did, and it had newer programs, like KDE3.xx. Which distro do you think I stuck with?...and for a contrasting point of view:
I just switched to deb3.0 from Mandrake8.0. I am beyond ecstatic with it. The install was easy (used 7cds from Linux Central), user-friendly, the defaults were acceptable even for a total beginner. I don't know a whole lot about Linux even after my past several years of constant use - the Redhat/Mandrake world has fogged my brain I guess. I've installed and used Redhat 5.0, 5.1, 6.0, Mandrake 6.0 and 8.0 over the past few years, and have been using Linux exclusively for that whole time. Redhat crashed often, and was a mind-numbing puzzle to update RPM's and figure out where things installed - nothing matched the Linux info I was reading on the web[...] I've been using Debian3.0 for 3 days now - fast and stable - tons of packages that are easy to get and install. Already I've learned how to start ppp from the console and how to do it via scripts (chat/provider/pon/poff) - something I could never do in Mandrake/Redhat - I normally just rely on kppp to do the job for me, and I never learned anything in the process!
I use a distribution called Debian (the word is a contraction of "Deborah" and "Ian") which is non-commercial. It is organized (or perhaps I should say "it has organized itself") along the same lines as Linux in general, which is to say that it consists of volunteers who collaborate over the Net, each responsible for looking after a different chunk of the system. These people have broken Linux down into a number of packages, which are compressed files that can be downloaded to an already functioning Debian Linux system, then opened up and unpacked using a free installer application. Of course, as such, Debian has no commercial arm--no distribution mechanism. You can download all Debian packages over the Net, but most people will want to have them on a CD-ROM. Several different companies have taken it upon themselves to decoct all of the current Debian packages onto CD-ROMs and then sell them. I buy mine from Linux Systems Labs. The cost for a three-disc set, containing Debian in its entirety, is less than three dollars. But (and this is an important distinction) not a single penny of that three dollars is going to any of the coders who created Linux, nor to the Debian packagers. It goes to Linux Systems Labs and it pays, not for the software, or the packages, but for the cost of stamping out the CD-ROMs. ... As far as I know, Debian is the only Linux distribution that has its own constitution (http://www.debian.org/devel/constitution), but what really sold me on it was its phenomenal bug database (http://www.debian.org/Bugs), which is a sort of interactive Doomsday Book of error, fallibility, and redemption. It is simplicity itself. When had a problem with Debian in early January of 1997, I sent in a message describing the problem to submit@bugs.debian.org. My problem was promptly assigned a bug report number (#6518) and a severity level (the available choices being critical, grave, important, normal, fixed, and wishlist) and forwarded to mailing lists where Debian people hang out. Within twenty-four hours I had received five e-mails telling me how to fix the problem: two from North America, two from Europe, and one from Australia. All of these e-mails gave me the same suggestion, which worked, and made my problem go away. But at the same time, a transcript of this exchange was posted to Debian's bug database, so that if other users had the same problem later, they would be able to search through and find the solution without having to enter a new, redundant bug report.Stephenson continues to discuss Debian's constitution, the Debian Bug-Tracking System, comparisons with experiences with a product more evil than Satan, and perverse economic incentives and the commodification of the operating system market. Well worth reading. Particularly the section beginning at MGBs, Tanks, and Batmobiles, which has one of the best descriptions ever of the whole Linux and free software phenonema:
It's a bunch of RVs, yurts, tepees, and geodesic domes set up in a field and organized by consensus. The people who live there are making tanks. These are not old-fashioned, cast-iron Soviet tanks; these are more like the M1 tanks of the U.S. Army, made of space-age materials and jammed with sophisticated technology from one end to the other. But they are better than Army tanks. They've been modified in such a way that they never, ever break down, are light and maneuverable enough to use on ordinary streets, and use no more fuel than a subcompact car. These tanks are being cranked out, on the spot, at a terrific pace, and a vast number of them are lined up along the edge of the road with keys in the ignition. Anyone who wants can simply climb into one and drive it away for free.
Can any of the resident deb-o-snobs explain to me what is so horked about rpm?In a word: policy. First, the package format itself is largely comperable with Debian's debs. It's not an RPM v. DEB thing, it's a no-policy v. policy thing. Debian isn't a packaging tool. It's a system, with policy, enforcement and execution tools, documentation, culture, community, and infrastructure. There are several cargo-cult attempts to replicate Debian's success by implementing portions of the model. "Debian uses DEBs, we'll used DEBs." "Debian uses APT, we'll use APT," etc. These efforts Don't Get It. Read my unwritten essay on why Neal Stephenson uses Debian. For background, read Cryptonomicon, Snowcrash, and Diamond Age. Neal gets technology, culture, and tribes. There are a number of corollaries. Among the principle ones are dependency resolution, treatment and handling of config files, file locations, documentation, and system upgrades. This is well-trod ground, and the best way for you to understand is for you to try it yourself. I've seen few people who've not been impressed. I've seen many who've become rabid partisans. Most of these partisans are veterans of other Linux or 'nix distros or flavors -- it's a partisanship based on familiarity with alternatives and technical merits. The principle arguments are abstracted in:
I've had a lot of Linux issues but rpm was never one of them. It works perfectly at the user level, and the installer level if the latter knows how to script things correctly. I've never had a corrupt database. What's wrong with rpm? Huh?If it works for you, I can't argue. As for needing to rebuild an RPM database, congratulations. Though I've found myself with twisted package lists, and have heard horror stories (Jim Dennis, of LinuxGazette? Answer Gang fame in particular) from people who've had borked RPM databases. RH may have addressed this issue, I don't know. Use of APT is fairly well documented: HOWTO. Could you point to comperable docs for SuSE's update tool? I couldn't find them. I'd ask how you'd approach the following tasks, though:
Mike's post about apt required three lines. SuSE's updater requires one "launch" command. Shrug.I haven't use SuSE's updater, and don't know how it works. You haven't used apt-get and don't know how it works. Arguing one line v. three (actually, Mike goofed -- only two lines are necessary) is like arguing that Beethoven was a better composer than Mozart because Ludwig's name is longer. What are the internal steps of the SuSE updater? The (simplified) mechanics of a Debian update are:
apt-get update && echo y | apt-get -d dist-upgrade apt-get autoclean...which performs the steps without user intervention. A slightly more verbose form of this script is included on the TWikIWeThey page referenced above. To check and apply suggested updates, it's recommended to first check to see what's going to be updated / removed, and then commit the changes. You're still left with two commands, but quite a bit of control as a consequence:
apt-get -s dist-upgrade | less # If desired, apply holds or removes at this point. apt-get dist-upgrade-- KarstenSelf - 18 Mar 2003
Mainly, what are the main differences between say RedHat and Debian?This testimonial (at Deja) is pretty comprehensive. Most significant single difference: Debian Policy, which spells out what Debian does and doesn't include, where things go, and how they are administered. This gives Debian an overal integrity and stability which are unmatched in the Linux arena. The BSDs approach it, but from another direction.
Other than the obvious ones like apt vs. rpm. Directory structure? Anything else?Yes.
apt and rpm are significantly different. Not that apt is hard to use -- apt-get install foo and apt-get remove foo are pretty much most of what you need, day-to-day. There are a number of different tools for working with the packaging system, you'll want to be familiar with deselect (individual package management), apt-get (distribution management), apt-cache (package searching), and aptitude (graphical front-end to most of the above). apt is far more graceful and robust than RPM in my experience, particularly when dealing with partial or failed package installations and removal. My one complaint is that it lacks signatures, however, a full MD5 checksum database is provided, with the debsums utility to work with it.
Other significant differences:
pppconf and Red Hat's printtool should get your dialup and printing configured. Everything else is relatively clean.
/etc/alternatives is where the question of "which vi is vi", etc., are resolved. You use the utility update-alternatives to modify these. There are a set of related tools for similar configurations.
Does Debian have a Pentium-optimized version?No. You can compile from sources, and this is pretty straightforward, but the benefits are small. See Re: How to make all build using --cpu=pentium?.
How much difficulty have you had with RedHat-oriented commercial software? Software in general?Specifically, none. I haven't installed a hell of a lot of stuff -- RealPlayer, a few versions of Netscape. In general, using
alien the fallback mode for Debian is that you're no worse (well, not much) off than using RedHat.
As I've stated, I have never used Debian... I would consider trying it if I knew what I was in for.The Debian Team Reeducation Committee has been dispatched....
SysVInit?. See filesystem.Uh. Which is which? I'm having a brain fart now so don't recall which method is which.
Administration. Debian believes in text-mode interaction. Where automated tools are provided, they don't break when, or prohibit, user modifications of configuration files occur.I have yet to see a tool in Red Hat that does this - of course, I really only use RPM on the command line and webmin otherwise. SuSE a long time ago used to screw some files up with YaST, but I certainly won't hold that against them - it was two years ago and a few versions removed from the YaST they use now. Just saying I understand why it's important
Installation. Reputed to be difficult, but it's generally worked well for me.Part of my problems with it are that it's generally old. Yes, I have a cable modem and can download the updates. But I'm sorry, RH7.0 came out a few months ago and is newer. Deb's got a dev branch going that's more recent, you say? Sorry, no dev in production, no matter how good. I don't even do that for the owner of the company, much less a user. We are getting much further off topic though, and suggest we start a new thread. I'll be glad to continue this there.
Debian:SysVInit. See filesystem.Uh. Which is which? I'm having a brain fart now so don't recall which method is which.
/etc/rc[S0-6].d/ plus /etc/init.d/ vs. RH: /etc/rc.d/(rc[S0-6].d|init.d)/. That extra rc.d gets fscking tedious. Minor nit. RH is adopting the FHS used by Debian.
This was something IIRC I ran into more either SuSE, Turbo, or Mandrake, don't recall which. However, RH's system scripts are typically very Byzantine. Try tracing yourAdministration. Debian believes in text-mode interaction. Where automated tools are provided, they don't break when, or prohibit, user modifications of configuration files occur.I have yet to see a tool in Red Hat that does this - of course, I really only use RPM on the command line and webmin otherwise. SuSE a long time ago used to screw some files up with YaST, but I certainly won't hold that against them - it was two years ago and a few versions removed from the YaST they use now. Just saying I understand why it's important
mysqld startup sometime, and tell me where your logs go.
In which case, you fail to understand the system. Debian installation can be used to create a full-fledged system, but the ideal is to install just the base you need, thenInstallation. Reputed to be difficult, but it's generally worked well for me.Part of my problems with it are that it's generally old. Yes, I have a cable modem and can download the updates. But I'm sorry, RH7.0 came out a few months ago and is newer. Deb's got a dev branch going that's more recent, you say? Sorry, no dev in production, no matter how good. I don't even do that for the owner of the company, much less a user.
apt-get the latest and greatest over the Net. While there isn't a kickstart tool, there is dpkg --get-selections > file and dpkg --get-selections < file; apt-get update, which can be used to clone the package installations from one system to another. As for the dev/stable branch, my experience is that RH stable installs tend to be as old as Debian ones -- except that they lack the security updates. Face it, right now, you're looking at RH 6.2 for stable, which was released, IIRC, March 8, 2000. Potato (Debian 2.2) is more current.
Epitome of RH v. Debian differences. Documentation. LILO. RH: /usr/doc/lilo-0.21/doc/User_Guide.ps. Debian: /usr/doc/lilo/Manual.txt.gz. You've got a system, you're trying to get it to fscking boot, for chrissakes, you don't have X you don't have a printer. Red Hat gives you a fscking document? What the FSCK am I supposed to do with that? Debian: zless /usr/doc/lilo/Manual.txt.gz. No problem. I've cursed this lapse of RH's any number of times. It's attention to detail, dozens of similar examples, that really ices the cake.
Debian: /etc/rc[S0-6].d/ plus /etc/init.d/ vs. RH: /etc/rc.d/(rc[S0-6].d|init.d)/. That extra rc.d gets fscking tedious.Ah. I prefer RH's way because one file for each program, symbolic links to determine what's in each runlevel rather than a flat file, and there's tools (ntsysv and tksysv) to manage the links for you. What's easier than a checkbox?
However, RH's system scripts are typically very byzantine. Try tracing your mysqld startup sometime, and tell me where your logs go.On that one, I wouldn't know. RH distributes Postgres by default, which certainly suits me cause I like a REAL sql database if I'm going to have to use one. For some people, Postgres vs. Mysql might matter, too, I'd forgotten about this one.
In which case, you fail to understand the system. Debian installation can be used to create a full-fledged system, but the ideal is to install just the base you need, then apt-get the latest and greatest over the Net.Yes, but I don't want to do it that way. I want a CD I can plop in a server and install 10 machines at once, without flooding my internet connection.
Face it, right now, you're looking at RH 6.2 for stable, which was released, IIRC, March 8, 2000.No problems with RH7.0. I was running 6.2 with most of the upgrades that were in 7.0 for months. AFAIK, you only got bit if you upgraded without testing it; i.e. expecting an update on a production server to be 100% a-o-k. But we can start a new thread for this one too.
You've got a system, you're trying to get it to fscking boot, for chrissakes, you don't have X you don't have a printer.If your system can't boot, does it really matter what language the stuff on the hard drive is written in?
Easier than a checkbox is a system that works and doesn't break. Of if it does familiarized you enough with what it is doing that you know where to look to figure it out.You're making the assumption that it breaks. I've never seen either program break, and have made extensive use of both.
And last but not least, yes it matters what format the Lilo documentation is written in! If you mess up Lilo but you have your rescue floppy, you can boot the floppy, read the docs, and fix things.If you have the rescue disk, you can get into X and read it. 'man lilo' works for me over remote ssh anyway.
As for 7.0, even LinuS? Torvalds is publically POed at it. I would link to the story but LinuxToday? appears to be down at the moment.Good for him. I still have yet to encounter any problems with it.
Do you know where your Postgres logs go?Yes - and if I don't, a quick look at the startup script shows me where. And yes, that's the RH built postgres RPMs, not the postgresql.org built RPMs (altho Lamar is a nice guy
Do you know how you would change the logging level?Not offhand, I haven't had the occasion to do so. postgresql.org offers me the information, if it's not glaringly obvious from either the startup script or the man pages (admittedly, I support the installation of postgres on our server at work, but I don't actually work in it if I can help it).
Suppose you need to write a script to monitor the logs for signs of suspicious login attempts, how would you do it?Yes, something that RH includes by default, altho their idea of suspicious and mine barely overlap. Just write a cronjob to look thru the appropriate log files for the appropriate keyword to send the appropriate email. I really don't see how that, or the question above, are determined by the distro, but more by the admins knowledge or lack thereof.
As for the rescue disk, at what point in installing on a laptop can you be confident that you have X up and running?Uh, same point as on a desktop? The only thing vastly different on a laptop is PCMCIA. Is this a trick question?
Besides which, how many rescue floppies have X on them?X is on the hard drive, which RH rescue floppies can point to (root=/dev/hda1). If you can't get to the hard drive, then you don't have a document to view anyway.
And I have not looked at a Red Hat install recently. Over ssh can you get all of the HOWTO documents?Yes.
/usr/doc/lilo/README. From the README:
There is also a LaTeX? version of this document in the "doc" directory. It is much nicer to read than pure ASCII.Wow. That ps file sure is important!
The point is that with a simple consistent layout, and a consistent pattern to their scripts, Debian's system is easier for an admin to learn without learning each application in detail.Gah! All my Red Hat logs go into /var/log, or at times into /var/log/
Personally I have never, even when starting, had problems finding documentation I could read in Debian. YMMV.Again, there's no problem with Red Hat, either. It provides it in ASCII and Postscript. It even includes directions on how to turn the Postscript back into if you lose the ASCII version!
Then maybe you can explain to me why mysql error logs on a RH 6.2 system end up in /var/lib/mysql/yelena.sf.zelerate.com.err, while they're in /var/log/mysql.err in Debian.n Where do they end up when you compile them yourself? And is that the actual path on Red Hat, or is it just /var/lib/mysql/gobbledegook? Anyway, I've never used MySQL?. It's not on the RH6.2 CD, altho it is on powertools. Says it's packaged by Red Hat, but I'm not downloading it to see where it puts logs. I invite you to, and feel free to email me the script, but I still think you're worrying about the wrong thing. It IS up to the admin to know where log files go. Someone else (Ben?) said they don't trust tools like ntsysv, I don't trust that a default install puts everything where I think it goes.
Log files should usually be named `/var/log/package .log'. If you have many log files, or need a separate directory for permissions reasons (`/var/log' is writable only by `root'), you should usually create a directory named `/var/log/package'.Note -- this is now not the same as the original, refactoring in process -- KarstenSelf 24 Sept 2002 Red Hat is including this package with their tools -- yes, it's powertools, but it's still an RPM. Which shows a key difference between RPM and .debs -- Powertools is not part of the Red Hat distribution, it's additional software packaged for it. The tools are not supported. And there's no policy for them to correspond to, outside the broad scope of such standards as LSB. Debian also has it's "extra" packages. Note that the 'contrib' section isn't this (one of the authors has had the pleasurable experience of having his head bashed into a wall repeatedly, until this sinks in). Rather, contrib is "packages that are themselves licensed DFSG-free, but depend on others that are not". There are also third-party Debian archives, outside the official branch. Typically, these are used to bootstrap incorporation of packages into the official archives -- Galeon, Mozilla, OpenOffice?, and KDE are all examples of packages, now included with Debian. Because this is typically a goal, and Debian has policy, Debian tends to be in the position that third-party packages are also highly policy dependent. The carrot is widespread distribution through a worldwide set of mirrors. The stick is -- thou shalt be policy conformant.