On Mon, Nov 27, 2023 at 03:20:53PM +0100, Julian Andres Klode wrote: > On Sun, Nov 26, 2023 at 03:00:11PM +0200, Adrian Bunk wrote: > > https://wiki.debian.org/PackageTransition > > #11 ?? > > Merge and remove: A and B existed; merge everything from A into B; A > > does not exist in new archive; B is the functioning package > > > > I'm currenly looking at a special case (and will also update the wiki for that): > > If a package takes over all files from another package but there are no > > file conflicts, is there anything in addition to Breaks that should be > > usedso that apt understands that this is a package merge? > > You should be using *Conflicts* and Replaces as per policy. While apt is > currently not making use of the semantic that Conflicts+Replaces > completely replace another package, a future version may, and other > tools (e.g. ubuntu-release-upgrader in Ubuntu) do. The alternative, which I would personally prefer here, is a "plugin depends main (>= version~)"; "plugin description contains 'transitional package'" and probably "main breaks plugin (<< version~)" aka #6. The benefit is that this change can be applied in more situations (e.g. already in an "upgrade" rather than "full-upgrade" step) and a user (and tools) doesn't need to investigate while performing an upgrade if this removal is bad or not as no removal is performed. Many people e.g. stop an upgrade if they see a package they like in the removal list waiting for the storm to hopefully pass… In my humble opinion we are burdening users way too often with package removals for no real benefit. > As a rule of thumb, Breaks are versioned, Conflicts are unversioned. I'm > not sure there are use cases for Conflicts without Replaces. Technically > this would be valid here from the semantics we have, but policy always > requires Replaces in that situation as well. It requires a Conflicts+Replaces because a Replaces is technically pointless, a Conflicts would be more than enough to avoid the file override situation as no files of pkg A are present anymore due to the conflict. So, the Replaces is reused here to give the two relations a new/additional meaning. Nice trick, but if that is a good thing… I am not as sure as you that Conflicts alone have no use case… we have quite a few examples in main but I lack the knowledge (and the time) to investigate why the individual packages/maintainers did that: We mostly thing in terms of file names to fight over, but there are a lot of finite things. It is e.g. rather easy to have conflicting browser plugins installed which both try to mess with webRequest(Blocking). Now, we don't declare that conflict in Debian and probably will never do as that would be counter-productive, but it is easy to construct similar interfaces: port numbers, dbus service names, … It is also why I am not convinced Conflicts+Replaces are a good indication for anything, including that a removal and/or upgrade is okay. The replaced plugin could be a pain-free invisible transition or require a complete rewrite of the configuration, both having the same markup. Especially in the later case multiple upstreams tend to form which all claim to be the true™ successor. Oh, and of course all these name conflicts like chromium, node and git kinda used Conflicts+Replaces relations, too, (or at least could have, they are so prominent that they were handled differently of course) even through there is no real interface to share or a sensible upgrade path between the involved packages, they are just completely overtaking the package name… not even trying to even provide a bit of the package interface aka a real conflict a user should really look into to keep their 2D sidescrolling shooter game, hamradio or GNU something… > but it's understandable that it's a hard problem because "Breaks" only > cause packages to be deconfigured and not removed (arguably apt will > remove them, but dpkg wouldn't on its own). Not that dpkg would remove Conflicts on its own either, so I don't really understand this remark. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature