Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Wed, Sep 4, 2013 at 8:59 PM, Sune Vuorela <email@example.com> wrote:
> On 2013-09-04, Steve Langasek <firstname.lastname@example.org> wrote:
>> Unless apt has gotten smarter recently (which is not out of the question),
>> no. It's a common misconception that apt will care about Provides/Replaces
>> for selecting new packages on dist-upgrade, but while it seems like a nice
>> idea, TTBOMK it's never been implemented.
The policy defines two uses of Replaces:
7.6.1 Overwriting files in other packages – this is completely ignored by APT
as that could be anything from "replacing a single file" over "fighting with
this package over a few filenames" to "replacing all files".
7.6.2 Replacing whole packages, forcing their removal – there is the common
believe that this allows all kinds of magic to happen, but no, it doesn't:
The hole paragraph doesn't mention upgrades once, because there is no
upgrade path. Not between mail-transport-agents, httpds, editors, "node",
"git" or "mplayer" packages (random examples, no critic).
So my simple question is, which combination of relations should that
be that tells a smart package manager to upgrade pkgA to pkgB ?
And does this combination also survives in the real world in which many
maintainers e.g. still haven't got the difference between breaks and
conflicts or depends, recommends and suggests?
> Over in RPM land, I think they have a Obsoletes relation for a 'you
> should consider this package a successor to <other> package'
APT has support for it since 2001. No idea how functional it is nowadays
though as the apt-rpm fork from there this probably came is just as frozen.
There should be a discussion about it in that timeframe, too. I remember
seeing one at some point in my history-digging, can't find it now though.
I think the most interesting point against such a relation might be:
(Not that we would be in a fight, but many people think we are, so lets
just add some fuel for them. KDE & Gnome works just as well)