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

[John Summerfield]

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

Edit the spec, rebuild from source. More recently, you can simply relocate 
the package (though I've not tried this).

> 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.
 
> 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
rpm --install the source rpm
rbm -bp the spec file

Read the docs, if happy
rpm -ba the spec file. 
If unhappy, you've got the source tarball(s) and patches the packager 
included - use them as you wish to build them manually. 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).

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

Indeed. But there is no added scope for the ungodly to commit muder.

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

The only way I know of doing this with rpm is to not use it. 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.

If the debian package manager tools can be upset by using it, seems to me 
a good reason to use something else.

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

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.

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. If a new version 
excludes a file from an earlier version, that old file stays there 
forever. In contrast, RPM would remove it.

If I wanted to remove sendmail, I'd use these commands:
rpm -qa | grep sendmail
and then
rpm --erase 

or rpm --erase `rpm -qa | grep sendmail`

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.

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

You're substantially correct in my usage of Linux, but it's more typical 
of business use than of home use: we have a network, the server runs from 
one power failure to the next, one machine runs Linux, NT, and 
(theoretically) OS/2. Internetting is fully scripted.

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.



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. Overall, though, the 
use of rpm is a Good Thing. Odds are I'd have had more problems building 
everything from tarballs.

-- 
Cheers
John Summerfield
http://os2.ami.com.au/os2/ for OS/2 support.
Configuration, networking, combined IBM ftpsites index.