Linux Distributions. Civilized Policy vs. Non-Policy debate

[gfolkert 0]

This is not a package manager discussion. What I want to know, those of you that evangelize *ANY* distrobution... I evangelize that you use something SANE... (I am going to be picking on RPM mainly cause it is usually RPMers doing the deed)

 

This is a FIA: frequently iterated argument.

 

An often asked Question:

Can any of the resident deb-o-snobs explain to me what is so horked about RPM?

• In a word:

policy[/list:u]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.

 

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:

• You might also want to look at this DistroWatch article,

Is RPM Doomed? (though it makes the classic mistake of confounding package formats with policy).

Nick Petreley's Make Debian the base standard: apt-get beats RPM.[/list:u]Another often spoken statemnet in this "WAR"

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: APT HOWTO. Could you point to comparable docs for your update tool?

 

I'd ask how you'd approach the following tasks, though:

• -- Post-installation, add a package with heavy dependencies to other packages, say, Galeon (depends on 28 packages, including numerous GNOME libraries, specific Mozilla versions, and other support packages).

-- Cleanly remove a package, leaving configuration files in place. (apt-get remove)

-- Cleanly remove a packge, purging configuration files. (apt-get remove --purge)

-- Cleanly update a package, with explicit control over configuration file updates. (any installation)

-- Prevent further updates to a specific package. (dpkg --set-selections & hold)

-- Provide required system functionality with a locally managed package, and inform the package management system that you're providing a dependency. (equivs)

-- Clone a system's packages to another system. (dpkg --get-selections, dpkg --set-selections)

-- Utilize specific package repositories of your specification (rather than only the vendor's repository, often heavily contended). I'll also note in the news in November 2002 -- the destruction of the Twente University NOC, which hosts several Debian repository and infrastructure servers (security.debian.org, non-us.debian.org, nm.debian.org, qa.debian.org). Existing replicated and distributed structure means that repositories can be rapidly replicated and restored elsewhere. In fact klecker.debian.org (non-us.debian.org) was back online in 12 hours.

-- Build and manage your locally-configured kernel as a package. (make-kpkg)

-- Utilize non-native packages within your package management system (alien)

-- Query a package and get its architecture without use of special output formatting directives. Hmm...thought I had a link to that, but no dice. man rpm(1) and see the --queryformat option.

-- Live minor or major system upgrades. No downtime required. And to answer the pedantic "but I don't want to do live system upgrades!" crowd: well then, don't, that's your choice. But doing them is a choice under Debian.

-- Pick of over software 10,000 packages (unstable). Stable distro? You're reduced to a mere 8,000+ packages. That's software built specifically for Debian, including policy.

-- Man pages. Required by policy.

-- Tools to check policy compliance. (lintian)

-- Integrated, open, bug tracking system. (debbugs)

-- Pick your bleed level: stable, testing, unstable, experimental. And if you want to get specific, pinning. (/etc/apt/sources.list)

-- General major post-installation system surgery: major addition/deletion of packages, without going through packaging hell. On Debian this is in fact the Recommended Way Of Doing Things if you're exploring the distro: get a base system installed, then add the necessary packages on an as-needed basis. Typically a newbie goes through a couple days of intensive additions, a week or so of significant adds (and possibly deletes), followed by a longer period in which one might add/remove a package or so a few times a month.[/list:u]To the chagrin of Debian Snobs everywhere, I've often said myself that *IF* an RPM distribution had "Debian Policy" behind it, I'd use it too. Conectiva of Brazil is the company that created apt-rpm and synaptic, and produces an excellent distribution of the same name. It is the first and, as far as I can tell, only company to attempt true continuous incremental upgradeability/maintenance in the Debian fashion on an RPM-based distribution.

 

So, you can see that BOTH DPKG and RPM are not the critical measure... the critical measure is Policy behind the building, testing and releasing of packages using a sane method of deployment.

 

Is this better Clutch? Please don't delete this one...

 

Thanks to Karsten M. Self for alot of the docs!

 

Edits: For spelling mainly, formatting and credits

[gfolkert 0]

You see this is why, why Debian users get upset and become "Snobbians" as most put... We argue facts and policy against other distro's religion...

 

Those of you that evangelize Gentoo... can't rebutt this... mainly there isn't comparable documentation and resources to show the procedure for doing a sane package realease. There are not guidelines for a QA process, or a TESTING (albeit short mabye) process... why?

 

RedHat, don't even get me started... RedHat breaks itself regularly. Mandrake same thing, Slack is better, so are others...

 

BUT, why do you supporters of "Cool" Distros not reply with counter points? Why must we drag you kicking and screaming into the discusson... mainly we are ready to show you our proof... I'd really like to see yours... Give me HONEST, straight forward answers to the Questions I asked in the first post.

 

I am not asking for a "cause G3N700 R3WLZ!" I am asking for a well thought out lucid, documentable re-butt/answer to those questions I asked before.

 

Gotta remember, this entire process comes out of the need for a choice of STABLE, RELIABLE and THOUGHTFUL deployment. Sure you can use your choice of "Stable", "Testing", "Unstable" or "Experimental". Those are just arbitrary Testing doesn't mean Broken... anymore that UNSTABLE mean "notuseable", but experimental DOES mean that... you break it "oh well".

 

The STABLE => TESTING => UNSTABLE is a process that *USUALLY* weeds out most difficulties before they get to stable... I personally run a combo of Stable and pinned certain thing in "testing" for servers. Now for Workstations I use, I run Unstable... Haven't seen a single day of down time... maybe some irritation at having to use a defferent X Environment fo a couple of days... but still working.

 

There is a common misconception that Debian is a "Our Way or the Highway" Distro... Well, just to pint out the obvious, I have Postgresql 7.2.4 with evrey-single option "ON" and Jabber with a *TON* of Optional Plugins... managed as local packages compiled by me with the Debian Build Systemmm... but with *MY* specifics for me. So I can;t see why or how people come to this belief.