Re: libplrpc-perl vs DBI vs mysql
Christoph Biedl wrote...
> About libplrpc-perl, This is obviously a result of the removal in
> unstable (#745477). In the current situation the warning you see is
> somewhat annoying if libplrpc-perl was installed through dependencies,
> not manually. But it cannot be uninstalled for the same reason.
More generally speaking, for quite some time I feared situations like
these were about to happen. There is a never-finished draft of an
e-mail here where I was about to ask how to deal with package removal
(from support that is) in general.
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.
If however the A package should receive more specific warnings, the
question are: Manual installations of A only? What kind of
dependencies, also Recommends: or even Suggests:? How to avoid this
list will turn unmaintainable due to its size?
The conclusion I came to was ending security support should be seen as
last resort only. 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. Recommending a backport
should be the least-intrusive solution. This libplrpc-perl case is
worse, though.
Just in case, not blaming anyone here. Remember, squeeze-lts is
declared experimental, we all are still learning.
Christoph
Reply to: