[ale] md5sum weirdness on firefox

[Jeff Lightner]

The dependencies thing you mention is what most people disliked about
rpm.   However as I noted earlier yum now will resolve dependencies for
you and even install the required dependencies when it installs the
package you're interested in.

 

________________________________

From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of
To: ale at ale.org
Michael B. Trausch
Sent: Wednesday, March 07, 2007 10:42 AM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] md5sum weirdness on firefox

 

On Wed, 2007-03-07 at 10:11 -0500, Jeff Lightner wrote: 

md5sum and Firefox in title - how is either of these a global issue with
rpm?


They aren't, particularly.  However, you'll notice that I was responding
to the comment about RPM not being bulletproof.  It never has been, and
that's the problem with it.  I don't know about anyone else, and I can
only speak for myself, but I will happily trade convenience any day for
robustness and proper function.  The latter saves more time in the long
run than the former does when you have a choice between one and the
other.  In fact, it reminds me of a saying: "If you don't have time to
do it right, you'd better have time to do it over," and I couldn't say
it any better than that myself.




So far as I know checking the sum of a file leaves it unchanged.
Transferring (downloading a file) can change it easily if you an ascii
transfer of a binary file.


This is true; the only thing that might possibly change is the file's
atime metadata.  Of course, file replacement can also change the hash of
the file, which is the assumed situation here in the case of system
binaries.  Those are usually transferred within an archive, anyway,
which means that if the archive were improperly transferred over the
Internet, the file would not have likely been able to been extracted.
Right?




Personally I find apt rather unwieldy to use and with the advent of yum
the dependency issues that were the bane of rpm users have mostly gone
away.


What, exactly, is "unwieldy" about it?  I seem to remember that simple
verification of packages and the like in RPM require all sorts of
command-line switches -- of course, this may have changed or I could
remember it wrong.  I do know, though, that APT/dpkg has been "ported"
to use RPMs for a backend, though I don't know that I would even trust
that.  I have seen very recent RPM-based distributions, with yum, throw
up all over dependencies, as well-by an update manager, even.  That is
something that should never happen unless you're running a non-release
version of a system (beta, alpha, somewhere in between).

Case in point:  I went to assist someone who was running the latest
release version of CentOS to manage their system, and after an hour of
downloading updates (and with only stock software installed on the
system in question) it complained about dependencies not being able to
be satisfied for one of the core packages.  That's something that
shouldn't happen, and I have only seen such silly things happen on
RPM-based systems.  Particularly more so since the updates were merely
bugfixes, and nothing that would require a distribution upgrade or
anything of that nature.

I've used five package management systems to date:  My own, Gentoo's,
Slackware, RPM, and dpkg/APT.  The best one in terms of combined
robustness, ease-of-use, and staying out of my hair is dpkg/APT.  It
just works, no questions asked, and I have never had to maintain its
infrastructure or try to repair it.  Gentoo's would probably be second,
and RPM is definitely last.  RPM is very much Redmondian, IMHO:  The
problems that it generates is sure to create some form of job security
for those that use it because of the woes you find with it everywhere.
;-)

    -- Mike


--

Michael B. Trausch 

fd0man at gmail.com

Phone: (404) 592-5746 

Jabber IM: 

fd0man at gmail.com
fd0man at livejournal.com 

Demand Freedom!  Use open and free protocols, standards, and software! 

 

-------------- next part --------------
An HTML attachment was scrubbed...