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

[John Summerfield]

> 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.
> > > It's been a while since I RPMed seriously, but doesn't this just take a
> > > source package and build then install it? Don't the files still end up in
> > If configured properly, rpm it installs it into temporary files. Prudent 
> > users do not build rpms as root; I have seen some do undesirable things.
> I don't quite understand this paragraph. :(
> Either it's grammatically unsound, or it is not made in reference to the
> text you quoted above it, or possibly both. Are you trying to say that
> rebuilding an RPM won't put things into messy places and leave them there?
> This is obviously true, but 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

rpm then takes the results of step 5 and builds the binary rpms. I have 
seen at least one rpm that was malformed so that in step 5 it tried to 
update the running system; a good reason not to build them as root.

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.

You can view a listing of the contents in much the same way you can with a 
tarball.


> 
> 
> > > > > that's an _advantage_ over unofficial RPMs. You put the files where
> > > > > they are, so you know what to remove. Who knows what an unofficial RP
> M
> > > > > might do?
> > > And by the time you've found out exactly what it's putting where and
> > > changed them to sensible places and parsed the install script and written
> > > things down so you can check that the uninstall script is sane before you
> > > run it and clean up after it, you could have just plonked a tarball
> > > somewhere sensible and configured it so as not to conflict with the rest
> > > of the carefully-managed system, with a few minutes left over to skim ove
> r 
> > > the instructions, or perhaps do something more important if you're as bus
> y
> > > a person as John is.
> > That's entirely nonsense.
> 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.

 
> > > > > > I use RHL because it works.
> > > Does it though? I'd be astonished if your haphazard approach to installin
> g
> > > third-party RPMs hasn't led to things breaking down here or there. Have
> > > you ever reinstalled a Linux distribution?
> > I have reinstalled, but always by choice in preference to upgrading.
> Mmhmm. So you will see my point. I don't install third party .debs and
> have never reinstalled a Debian system in my life, _except_ for when I
> used an unofficial broken version from Infomagic. (My first experience
> with Debian and almost enough to put me off, but in the end it did teach
> me to use the official packages)


Whether one chooses to install third-party packages has nothing to do with 
the package manager. I AM selective about where I get them; I'm happy to 
get rpms from IBM, redhat and its mirrors, and I have also installed 
software from NEC and Fujitsu (and at least one of its subsidiaries). And, 
of course, device drivers for any hardware I get (though that hasn't 
happened with Linux).

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

> 
> > > > > If something is packaged with only one distro, I wouldn't touch it. :
> )
> > > > Caldera has shipped stuff not available from others at times; I think i
> t 
> > > > recently had SO included, and cost heaps less than RHL.
> > > Well, apart from my inherent distrust of non-free bloatware like SO... I
> > > though most of the distros included it, though many will of course have a
>  
> > > core distribution of Free software?
> > There was a first, and I think it was not RHL.
> There was a first to include it in their standard distro, but they didn't
> do anything to prevent it from installing on another distro. Isn't it far

I never ever said anything about packagers including software that would 
not install on other distros; I was going to buy RHL 6.0 until I found out 
the price because it included Viavoice SDK. VV would install on Debian 
with, I expect, about the same difficulty as Apache; you would, of course, 
require glibc 2.1 (IBM's choice).

> easier to grab what you want from the new CD and install it on your
> existing system?

That's often an option. As an existing Red Hat user, I'm likely to do 
that. If I were a new user, I'd more likely install the whole distro.



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