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
