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

Greg Mildenhall greg at networx.net.au
Sun Feb 27 01:02:55 WST 2000


On Sat, 26 Feb 2000, John Summerfield wrote:
> > On Thu, 24 Feb 2000, John Summerfield wrote:
> > > > On Wed, 23 Feb 2000, John Summerfield wrote:
> > > > > > On Tue, 22 Feb 2000, John Summerfield wrote:
> > > > > > > Most times I can find an rpm created for Red Hat, though often
> > > > > > > for the wrong version.
> > > > > > And hence rarely better than a tarball, and usually worse.
> > > > > I can type rpm --rebuild a darn sight faster than I can untar and
> > > > > read the instructions.
> > what about when you install the RPM? Will it's install scripts to evil
> > things to your system, regardless of where you put the unpacked files?
> The build process involves these steps:
> 1	Untar source
> 2	Apply patches
> 3	Configure
> 4	make
> 5	make install

Aaah, OK, I see where we have our wires crossed. For me, Step 5 is:
5(a) Read the make install script.
5(b) Work out what needs to be done to make the program work.
5(c) Do this with minimal affect on filesystem outside of /usr/local/foo.
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.

It is because RPM cannot do these things that I consider it a poor
substitute for my own brain when dealing with tarballs.

> When instaling the result, you have the option to not run preinstall and 
> postinstall scripts. However, I don't see that they're more hazardous than 
> 'make install' as root.
But they might be just as hazardous.

> You can view a listing of the contents in much the same way you can with a 
> tarball.
But that will not tell you how, for instance, your /etc/inetd or
/etc/rc.local files will be editted, and whether this will obstruct the
future smooth functioning of your packaging system.

> > So how do you install rogue RPMs?
> I don't. It's possible I could get a trojan; but debian won't prevent
> that. Nor will tarballs.
Sorry, "rogue" is probably a bad choice of words. I meant non-official.

> 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.

> > > One of the impediments to uprading another box is software that's 
> > > installed (and working) that is installed from a tarball.
> > But at least you put it there and hence know where it is, and at least it
> > hasn't altered your package database, potentially blocking/sabotaging the
> > upgrade.
> 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.

I think we have differing respect for packaging skills of our distributors
vs. third parties. Only reasonable when we have different distributors and
probably different third parties for all I know. Probably I am also more
experienced at making things work from tarballs and making sure the
changes are orthogonal to the package management - this would be at least
in part because Debian provides far more detailed directives for system
integration. 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.

-Greg




More information about the plug mailing list