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(a)atrpms.net> 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