On Mon, Jan 24, 2005 at 05:29:55PM -0500, Jeff Spaleta wrote: > On Mon, 24 Jan 2005 23:08:47 +0100, Axel Thimm <Axel.Thimm@xxxxxxxxxx> wrote: > > The current solutions are too hackish to be even considered a natural > > approach. Look at gcc34 and the required obsoletes in gcc to deal with > > this cruft. A proper scheme of coexisting packages for certain classes > > (libraries, compilers, interpreters) layed out once and for all will > > bring piece here forever ;) > > But is there clean way to indicate to a user that an older version of > the library is no longer being maintained and has "expired" and won't > be getting any security updates? This is not not just an issue of > finding the unused libs. An unmaintained library package could still > be in use by an application. How do you make the admin aware that a > library package they are using is no longer being maintained so they > can review whether or not to keep it and the applications using it > installed? Unless there is a mechanism by which admins are informed > of an expiring library so they can make an informed decision, i don't > feel its worthwhile to encourage the accumulation of older libraries > at all. Not sure how this fits in here. These are valid points you make, but they are valid for both the current and a soname-in-the-rpmname scheme :) The problem you are addressing is much larger, if you do a RH7.3 -> RH8.0 -> ... -> FC3 upgrade party you'll find that your system has quite a lot of old unsupported cruft left over. Any deprecated not replaced package will be there including its security implications. -- Axel.Thimm at ATrpms.net
Attachment:
pgpoHNY1KxjnV.pgp
Description: PGP signature
