[Gllug] RH rpm upgrading

[James de Lurker]

Doug Winter wrote:
> On Fri 06 Jun James de Lurker wrote:
>>Wed, 04 Jun 2003 18:07:34 +0100  Martin A. Brooks wrote:
>>>At 16:36 04/06/2003 +0100, you wrote:
>>>>Rubbish. RPM can do all of that with various combinations of %doc, 
>>>>%ghost,
>>>>and pre- and post-install scripts.

>>Often impractical where a user might "jump" any number of intermediate
>>release stages in the upgrade of an application. It is too expensive to
>>consider and program for every eventuality in the spec file.

> Debian manage it, for upgrades by two debian releases iirc, and they
> don't even pay their developers :)

Redhat are spreading themselves too thinly to possibly keep up with all
combinations of releases, and timely third party SRPM contributions seem
to be waning.

But to keep to the point, it doesn't matter how much better apt-get and
Debian's packaging scheme is. It is still a packaging scheme, and any
weirdness on the part of the _application_ developers' toolsets for
maintaining that application are entirely opaque to said package manager.

An experienced person in that particular application has to analyse and
code for all the possible circumstances and exceptions when attempting
use the package manager's scripting to do all this work transparently to
for an installing admin. It rarely happens. The safest and most sensible
approach to keep a stable working platform is to follow that old assembler
declaration: Assume nothing <*grin*>

FWIW I was pretty miffed by RedHat effectively labelling me as "an 
enthusiast" which, in a business sense, is derogatory. Ironic really, as
three years of effort on my part have introduced RH Linux in corporates
for a number of bespoke systems. Now you add further confusion to Linux
advocacy business solutions and perspective. "Toy" distributions.

Debian beckons me because it _is_ more easily "upgraded" with other things
that are a nightmare of patch merging reconciliation to get working 
properly in a deadrat environment. Trying to get loop-AES packaged for
RedHat using kernel.org 2.11z utils as a starting point instead of the
hugely ancient backported fixed-up 2.11f in RedHat 7.2 is a development
project in its own right. Grrrr. This has to work with the vastly patched
RedHat version of the reference kernel.org kernel, as well. Bah.

Let's keep it in persepective, though. I still remember the pain of 
managing armies of Microsoft "updates" and running an NT centric SME 
business. Service Packs that did Bad Things [tm] to intergrated networking
with non MS equipment. Whatever RedHat does in it's own attempts at "lock
in" cannot possibly get as bad as the reviled M$ modus operandi. The
samba team, bless 'em never had source code access.

And: I have a huge personal investment in learning rpm. When you get to
my age ( coff coff ) it is sometimes better to use an older tool <ahem>
to get the job done well, than a new one that does more, more quickly, but
still fails to satisfy an application upgrade to the latest version.

Computer science, like art, often mimics life <G>

-- 

   -- James

 From and Reply To are INVALID.

All public postings use munged headers[1]- To contact me off list:
   1) Remove "M U N G I E j u m p" ONLY: leave that "nospam" in there!
   2) change "hotmail" 2 "myrealbox" after the @



-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug