Re: corel

[Mark Blunier <blunier@ocslink.com>]

On Sun, 12 Dec 1999, Steven Pritchard wrote:
> Mark Blunier said:
> > Why are you disappointed when it is base on deb, which is better?
> 
> That's purely a matter of opinion.
> 
And maybe one day, you too will see the light. :)


> IMNSHO, the big difference between Debian and the RPM-based
> distributions is the tools.  There is no question that the Debian
> tools are *way* ahead of RPM.  Red Hat has only recently made a
> (somewhat feeble) attempt to remedy that with gnorpm.
> 
> On the other hand, I have yet to be convinced that the Debian package
> management system as a whole is superior to RPM.  From what
> (admittedly little) I've seen of Debian's packages, RPMs are cleaner
> and easier to build.

Yes, they are easier to build, as they required less information about
other packages to  build a proper rpm.  Debians builds are a bit
confusing to do, especially by scratch, but with the dpkg build
scripts, much of the tedious work is done for you. 

>  Yes, the dependencies could use a little work
> (why should someone necessarily need to know that a dependency on
> libhistory.so.3 means they need the readline package installed?), but,
> again, that's a tools issue, not an issue with the packaging system.

As an installer, I don't need to know if it is installed, but If I
install package fred, and I don't have libhistory.so.3 installed, I need
to have readline installed so that fred works.  Likewise, if I decide to
removed readline, I'd like to know what programs I will be breaking by
doing so.

>  > Debian is easier to upgrade and maintiain due to its dependencies,
> > predepends, recommended, and suggestions for the related packages,
> > post-install scripts, and purge-scripts for deleting packages cleanly.
> 
> RPM packages have dependencies, pre- and post-install, and pre- and
> post-remove scripts.  I'm not convinced that the various levels of
> dependencies in Debian packages really buy you much.
> 

The main one is the 'pre-depends', (which is a pathetic name).  There
are some packages that must be installed in the proper order to keep
things working, such as when upgrading to elf or glibc.  Normally
it is not needed, but its always nice to have the right tool for the
job even if you don't need it very often.

> That's not to say that the Debian system sucks really or anything...
> It just really seems though that the people who say how great the
> Debian system is don't see the distinction between the tools, the
> package format, and the rest of the system.

Likewise, I'm not saying rpm sucks either. (I might say slackware sucks,
but its been so long since I've used it, I probably shouldn't).

There is a difference between the tools and the system.  I cringe every
time I see someone say they want a unified package system.  More
important that the tools that make up the system, is what gets up
installed from the tool.  If someone were to make a .deb file that
puts stuff in the wrong location, installs redundant programs, but
doesn't identify them, and etc, that is what causes problems.  Debian
seems to do a better job of putting things in the right location and
doing things the 'right way'.  This is of course a matter of opinion,
and it is also why many people get turned off of Debian.  The read
the mailing lists and see people bickering over stuff they don't
understand, or at least don't appreciate, and think the Debian
developers can't get along, or are being petty and childish.  While
to many people it doesn't matter if emacs belongs in /usr/emacs or in
/usr/bin, but those of us that like to see a distribution that is put
together following guidelines based on logic, rather than tradition,
Debian is better.

> 
> RPM has several features that I *really* like.  First, there's the
> distinction between source packages and binary packages (which, oddly
> enough, is really more of a tool issue, since they use the same
> on-disk format), and the whole spec file notion of source and patches,
> which lets you easily build pristine source-based packages.  (Now, if
> only rpm was smart enough to take a URL for source and go fetch it for
> you...  Then rpm could build a package given only the spec file.)

Debian most certainly makes a distinction between souce and binary
packages.  The pristine source ends in .tar.gz.  There is the .diff.gz
file describing the changes made to the souce to get what is compiled
to create a .deb package, and of course the .deb, the package that
is installed.  What more could you want, besides a 'make world',
that would download and compile everything, optimized to your cpu?

> 
> Second, I do like it that RPM packages, whether source or binary, are
> one file, rather than some funky directory structure or something.
> (I'm not pointing fingers at anything in particular here...  I've seen
> this on other operating systems.)  Now, if only the Red Hat people
> hadn't taken the easy route of using a cpio-based on-disk format (so
> they could just massage the file and exec cpio, rather than having to
> do work themselves), instead of an easier-to-manipulate tar archive...
> (It's a shame that nobody pointed out to the developers of rpm that
> GNU cpio can handle tar archives.)
> 

I'm not sure what you are talking about by the 'some funky directory'
stuff.

> Hmm...  This email is getting too long, and I'm probably boring all of
> you who have actually read this far.  :-)

Its no fun having a discussion if you don't read the whole message.
> 
> Steve
Mark



--
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.