[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)



On Fri, Sep 6, 2013 at 7:05 PM, Steve Langasek <vorlon@debian.org> wrote:
> Now, maybe apt could consider a package a replacement only if pkgA
> Replaces/Provides pkgB, *and* pkgB is no longer available.  Are there cases
> where that would give the wrong result?  Is it practical to implement?

Depends I guess on how much you value slight derivations from the norm.
APT detects "obsolete" packages in its ProblemResolver and gives those
a small penalty in conflict resolution, but I am not sure its a good idea to
not only increase the penalty but let it cause actions by itself:

Many people have multiple releases in their sources.list, so a package is
not really disappearing – or takes quiet a while until it disappears.

On the other hand packages sometimes disappear "temporarily" in testing.
Also, sometimes packages disappear from stable – so while its a good idea
to do something about those, I would say this is the wrong way of doing it
as such an automated change contradicts stable.
(and it doesn't work for the more common cases of packages which disappear,
 but have no replacement as such)


What MIGHT (I haven't really though about it yet) work is limiting it to
provides+replaces(+breaks) in the same source package, but I am not sure
it makes that much sense to introduce complex rules for dependency relations
if the current "simple" rules are already not understood by everyone
(like breaks vs. conflicts).


Personally, I would say we need a hints file just like britney and co have,
but for package managers which tells them that this package is gone and
a) can be replaced automatic by foo
b) the user should decide between foo, bar, baz (this info is usually
    available in prosa in the RoM/RoQA bugreport)
c) has no (free) replacement
d) is no longer needed
…

Not that this would make the life of a maintainer necessarily easier,
but it at least frees the user (and the package manager) from deciding
if this remove requires user-attention or is just boring house-keeping.


Best regards

David Kalnischkies


Reply to: