Moritz Muehlenhoff wrote...
> On Wed, May 28, 2014 at 10:21:10AM +0200, Christoph Biedl wrote:
> > So opening a can of worms: Given package A depends on package B,
> > perhaps even through a third package. Now support for B is to be
> > terminated. Shouldn't there be precise warnings for A too, at least to
> > some degree? At the moment there's nothing, so users will have to find
> > out on their own about that on their own: Removing B "I don't need
> > that", then realizing this kills some parts of the installation.
> > That's not good.
>
> I suppose any solutions which tries to display affected reverse deps
> will introduce a lot of complexity for little gain (as by the examples
> you already provided)
Indeed. I've tried to create an automated list from a source package,
and ended up with having to write a full-featured dependency resolver
(but resisted the temptation) and e.g. asterisk having reverse
dependencies on several hundred packages, some over a chain of ten
hops.
> We should rather document the general approach (e.g. running
> dpkg --dry-run remove DROPPEDPACKAGE)
I am preparing a Wiki page for d-s-s that will also contain a small
selection of "theses packages might be affected, too" and generic
suggestions how to proceed..
> > The conclusion I came to was ending security support should be seen as
> > last resort only.
>
> Of course.
Let me re-phrase from above: Impact of removing a package is much
worse than I thought.
> > If this is inevitable, looking into the dependencies
> > to learn about the implications must be part of the decision. Users
> > need an information how to proceed, that is a part of the retirement
> > notice and that's why I suggested URLs in the d-s-s notifications:
> > Some 60 characters simply are not enough.
>
> Alternatively we can ship README.foo packages in debian-security-support
> when a package is EOLed.
We can still do that, too.
Christoph
Attachment:
signature.asc
Description: Digital signature