TCLUG Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [TCLUG:15263] Reading Red Hat rpms





> -----Original Message-----
> From:	Scott [SMTP:pope@ossuary.net]
> Sent:	Tuesday, March 28, 2000 1:22 PM
> To:	'tclug-list@mn-linux.org'
> Subject:	RE: [TCLUG:15263] Reading Red Hat rpms
> 
> On Tue, 28 Mar 2000, Schlough, Mark wrote:
> 
> > What's missing/wrong with rpms?
> > or 
> > What's deb got that rpm doesn't
	[Schlough, Mark]  
	Thanks for your reply.  I was wondering about this.  It would seem
from your statements that SRPM would be a better option than RPM.

>      It has nothing to do with .deb being better.  In my stance .deb's
> have no standing at all.  My problem with rpm lies in the fact they're
> very restrictive in where stuff can be installed (try using the flag
> for a custom prefix sometime, it won't work 99% of the time), they're
> distributed in a crazy base & devel scheme, and precompiled binaries
> set up until recently for 386 procs don't thrill me.  Plus the goofy
> way the stuff gets versioned, take a look at redhat's kernel updates
> sometime (2.2.10-123812308912343244324 instead of 2.2.14 :P), is rather
> messy.  I haven't dealt with .deb's much because on a whole I think
> debian is a pretty poorly designed dist except for their version of
> bsd's ports system, apt-get.  
	[Schlough, Mark]  
	I found a utility for rpm called rhup (or maybe rhud) that apears to
be equivalent to apt-get

> The only package format which I can truly
> see myself liking is Stampede's.  Source & binary in one neat little file
> which can be untar'd and recompiled.  For now though I'll stick to
> plain tgz source.  If you're paying attention to where things get
> installed, upgrading a prog with source is just as easy as a rpm.
> 
> 
	I guess the main thing I like about the rpms is that they also do
the dependency check. This seems to simplify the dependency stuff that
tarballs may break without the guidance of a diligent (maybe anal) admin.
..... Maybe I've just been lucky.

	Mark