fedora-l] Re: RPM upgrade discussion

[R P Herrold]

On Thu, 1 Jan 2004, Lucas Albers wrote:

> Bill Nottingham said:
> 
> > Yes, but pushing a new RPM with this will cause problems for
> > people installing original packages in the meantime.

> Won't this also break upgrades?

Yes, probably.  I feel one constraint on updates in an EOL
product should arguably seek to be as minimal and general in
nature, and support a given Major.Minor release as possible.
[somewhat in line with the Unix principle of 'least surprise']  

This was articulated in the rather nice Mark Cox piece at:
	http://www.redhat.com/advice/speaks_backport.html
wherein he notes:
>  We can't please everyone, and backporting annoys some users 
> who always want to be upgraded to the latest and greatest 
> releases. However, in general, customers are more interested 
> in stability, and the ability to minimise the changes needed 
> for their QA and deployment.

If a requirement of using fedora-legacy content is to also
move to a version of RPM which, during its support life RH QA
or RH Corporate did not see fit to issue for pre-RHL 9 (and
soon, all RHL variants), there is a strong obligation for
'fedora-legacy'to state this clearly to the sysadmin using it.

In the EOL context (as fedora-legacy project is), I lean to
the side for minimal 'intrusion', to satisfy security
requirements, but not to add functionality.  

There is a known path for recovery from the RPM 'stale locks'
issue which does NOT require a non-security RPM 'update' --
Others may come out differently in all good intent; but except
for the unresolved subtle RPM exploit path mentioned on a
public list (which should properly be resolvable as the
SELinux capability extensions are rolled in [which will not
happen in fedora-legacy]), a change to rpm-4.2.x is just a
"upgrade to the latest and greatest."  No thanks.


I saw also in this thread, some critique of the
http://www.rpm.org/ website continuing mention of using
--rebuilddb, in the process of recovery from 'stale locks' in
some RHL versions.

While it is an interesting datum that one person, using some
of Red Hat's (and self-built variants) in an unstated number
of hosts has found '--rebuilddb' unnecesary, it is also clear
that several reporters on the RH hosted rpm-list _have_ so
reported the utility of this approach in resolving such
problems.

As there is more to RPM than Red Hat's RHL variants (heck, I
answered a question on an RHL 5.2 rpm variant the other day),
as that site's editor I see no compelling reason to alter that
site's advice.

 -- Russ Herrold