On Fri, Sep 06, 2013 at 03:16:34PM +0100, Simon McVittie wrote:
> On 06/09/13 10:17, David Kalnischkies wrote:
> > For example, you made mplayer2 now an upgrade for mplayer.
> > I am not sure that is what their maintainers/upstreams intend.
> > (maybe it is, but I am not keen on letting foo2/foo-ng maintainer
> > decide what is a good upgrade path for foo – that should really
> > be decided by foo maintainer).
> In controversial cases, can't we avoid this by social pressure ("don't
> do that, it's rude")?
The issue David is raising is that this is a semantic change; while many
packages would work fine by interpreting Replaces+Provides the way you
describe, there are some that wouldn't, and under Policy these packages are
not "wrong" today. How do we transition to this new behavior on the part of
apt without inconveniencing users with wrong results?
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?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature