On Wed, Sep 4, 2013 at 8:59 PM, Sune Vuorela <nos...@vuorela.dk> wrote: > On 2013-09-04, Steve Langasek <vor...@debian.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: Package: aptitude Obsoletes: apt (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) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fB_rmGTBPRYzu5HSJo_=eyigfqrlqtmzyh0ebjlg1u...@mail.gmail.com