Why I use Debian. Was Re: [plug] Mandrake - printing

[Greg Mildenhall]

On Sun, 27 Feb 2000, John Summerfield wrote:
> > 5(d) Ensure that any playing with existing files, or adding things to
> >      existing directories is done in accordance with Debian's way of doing
> >      things, and will not upset dpkg in future.
> You'd hardly use rpm for debian; neither would you use dpkg for rhl.
OK, so on a Redhat system, you would obviously substitute "Redhat" for
"Debian" and "rpm" for "dpkg" in the above sentence.
> > It is because RPM cannot do these things that I consider it a poor
> > substitute for my own brain when dealing with tarballs.

> If you want to do that, get the source rpm then
> <effectively do the step above after extracting the tarball from the
> .rpm, with the exception that just maybe the .rpm's scripts will be good
> enough to just run.>

> Ideally, you'd create binary rpms that match your requirements and
> install those (and maybe archive them to CD as you'd have a unique
> version).
Yuk. Apart from perhaps ease of duplication, why would you do that?
What possible benefit could arise from having an entry in your package
database that does not correspond to an official package. At best it will
just be a waste of time, at worst, you could throw a spanner into the
working of an otherwise consistent vanilla system.


> > > Whether one chooses to install third-party packages has nothing to do
> > > with the package manager.
> > It certainly has. You can prevent the correct functioning of the package
> > manager when installing, upgrading or removing packages in the future.
> The only way I know of doing this with rpm is to not use it. 
What about inserting a package with invalid dependencies that will block
an upgrade of your system? What about a package which inadvertantly
collides with the future Redhat namespace? (In this instance, are you
even going to be able to work out what's wrong, let alone fix it?) What
about a package that depends on a local packaging of some library that
conflicts with the standard Redhat packaging of that library, hence
breaking the install of any other software dependent on the library?

None of these are situations I am inventing. They have all happened to me
because of installing incorrectly-constructed/integrated .debs and .rpms.
As a general, though not infallible rule, official .rpms from Redhat are
correctly-constructed and have dependencies that integrate smoothly with
the rest of your system. As a well-nigh infallible rule, .debs will be
well constructed/integrated.

> It does not know about any package it doesn't install, and its uninstall
> doesn't remove any files used by a package that it didn't install.
Which is a very good thing. It means your plain vanilla guaranteed-to-work
system is not adulterated by impure packages.

> If the debian package manager tools can be upset by using it, seems to me 
> a good reason to use something else.
It's not the tools themselves, it's the dependency structure. It is very
well organised (Redhat's is organised quite well, too, these days) and
strenuously tested _within_the_scope_of_official_packages_. This is why my
potato/woody hybrid has been incrementally upgraded from bo (a libc5
distro) over the last 2+1/2 years with barely a hassle. (a couple of
times I have used software from the unstable branch after it seemed to be
final, only to find things change in the hectic run-up to the freeze.
Both of these problems were solvable with dpkg and apt, not by edited
the package databse manually or using dpkg --force).

If you introduce factors into the dependency structure that the official
maintainers cannot predict or account for, then you run the risk of
scuttling all the well-laid plans of the maintainers and release
coordinators. Probably the worst incident I've seen was a KDE .deb
breaking the menu standards in such a way as to render all
standard-compliant window managers completely menuless. Thankfully this
happened on someone else's system. :)

> > > > > One of the impediments to uprading another box is software that's 
> > > > > installed (and working) that is installed from a tarball.
> > > The fact that the package database does not reflect the installed software 
> > > sabotages the upgrade; obsoleted versions can't be removed properly.
> > That affects the third party software, which is only to be expected. Far
> > better that than to affect your core distribution.
> Since (here) vendor software is all packaged with rpm... However, I COULD 
> extract the tarball from a src.rpm and manually build and install that. 
> Then rpm with be stuffed wrt that package.
Then you haven't installed it correctly. There should always be a way to
install the package that is completely orthogonal to the package
management system - i.e. with no side-effects in either direction. (If
not, then Redhast needs to have a good hard look at it's packaging
guidelines and fix this) Once you alter the package database, you've lost
that orthogonality, and can no longer trust your system to behave the way
an offical Redhat one would.

> Almost, but not all, of my software is controlled by RPM. The software 
> that is not installed by rpm is least maintainable; upgrading to a new 
> version does not automatically remove the old one.
Thank goodness. Automatic software removal should be done by an official
tested script or not at all. far better to do it by hand than to take pot
luck and see what some random .rpm decides to delete for you.
> If a new version excludes a file from an earlier version, that old file
> stays there forever.
I think we have different expectations of the competence of a sysadmin.
Perhaps your admin is incompetent - I've seen my fair share of those. :)

> If I wanted to remove sendmail, I'd use these commands:
> <rpm -blah>
Since sendmail is an official RPM, you'd be mad not to do it via the
package management system.

> Almost all the software I see is packaged as an rpm, and almost always the 
> latest version of it; replying on it is no hardship. I choose sources 
> where the packages are built by RHL users for RHL.
Do you mean built and tested by RH, or built and not tested by RH users?
There is a substantial difference.

> Most times a package is an upgrade to an existing RHL package and I want 
> it to replace the existing one; for example there's a new version of 
> Apache out - I got the announcement overnight. I also got two separate 
> announcements about sources of rpms for it.
But of course. It's an official package. Only sensible way to do it.

> > I think we have differing respect for packaging skills of our distributors
> > Another source of our differences is that (as far as I know)
> > most of your Linux usage is in home or workstation settings, whereas much
> > of mine has been on theoretically 24/7 networks and with other people
> > dependent on things going smoothly - as Matt has said before, paranoia is
> > the #1 virtue of a sysadmin - if you want it done right, do it yourself.

> Your usage of Linux is doubtless more intensive, but I have more breadth - 
> I was doing your kind of job in the early 70s, when a big mainframe had 6 
> Mbytes of RAM (4K DRAM chips individually soldered to the board), 
> semiconductor memory was new (about then we bought a bunch of computers 
> with genuine core memory), the latest in hard disk drives was 100 Mbytes.
Mmmm, fun. Was this the day when you could only use software supplied by
the vendor on a typical mainframe?

> I do recall an rpm that stuffed me; when I upgraded to kernel 2.2 I 
> installed the ipchains rpm. The packager declared that it 'obsoletes 
> ipfwadm.' Consequently ipfwadm got removed and I no longer had a 
> 2.0-compatible firewaller. The packager stuffed up.
And this was a package officially tested and integrated by Redhat. Imagine
installing an RPM that was created by the author of the software with no
regard to the Redhat packaging guidelines and tested on his machine only.

> Overall, though, the use of rpm is a Good Thing. Odds are I'd have had
> more problems building everything from tarballs.

But of course. Package management is a wonderful thing. Especially when
your distributor goes to the right lengths to ensure smooth integration
and working of their packages. Several orders of magnitude better than
installing everything from tarballs. Throw a third party spanner into the
works, though, and you jeopardise that reliability. It's usually too big a
risk for a serious administrator to take.

-Greg