Bug#1069687: librust-bitflags-1-dev: fails to co-install
Hi! On Tue, 2024-04-23 at 07:51:36 +0200, Helmut Grohne wrote: > On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote: > > Is the only workaround dropping Ma:same here ? > > I see very little alternatives. We must choose: > > * Do not combine M-A:same + Provides: foo + Breaks: foo. > * Fix dose/apt/dpkg to agree on what this means. > > If we were to adapt dose and apt, they's simply arrive at the conclusion > that M-A:same would not work here so that really is not what you'd want > here. This amounts to fixing dpkg to allow this very combination in the > same way that apt and dose allow it. So yeah, changing dpkg could be an > option. Ccing dpkg-devel about it. > > The first alternative means that we must not combine them at the same > time. As we very much want M-A:same, we must not have this combination > of Provides and Brekas. Keep in mind that they serve slightly different > purposes. We have Breaks + Replaces and you can only replace a real > package but Provides introduce a virtual package. In effect we're > dealing with a package that sometimes is virtual and other times is > real. We can choose different names for these uses. The real package > could be renamed and also provide the virtual facility. All of them > would now provide the virtual one as virtual only and none of them would > have the virtual name. The Breaks and Replaces would be updated to match > the real name. > > This may not work for the in-archive situations right now as Breaks and > Replaces may still be necessary for upgrades, but it is something that > may work in future situations of the same kind. So, is the proposal for the dpkg change to make it ignore self-Provides within a pkgset (that is all arch instances for the same package name)? (Also I guess we'd get into what does self-Provide mean within a pkgset.) While the behavior might seem like it makes sense in this specific case, the new semantics might seem a bit wonky? For starters Provides (unless arch-qualified) currently inherit the arch from the providing package. Breaks (unless arch-qualified) assume an arch-qualifier of "any". Either we'd need to consider the Provides from one instance extend to the whole pkgset (ignoring their arch-qualifiers or subverting them?), and then installing new instances (with different Provides for example), would affect what other instances are providing, which is action at a distance and could have very surprising effects. Or we might need to check that what is being broken from one instance is being provided exactly in the same way (ignore arch qualifiers again, and match version if present) by the current instance and the breaking one? (Although perhaps I've got all this wrong, or there's a better and more obvious model for the semantics. :) Thanks, Guillem
Bug#1069687: librust-bitflags-1-dev: fails to co-install
On Tue, Apr 23, 2024 at 07:51:36AM +0200, Helmut Grohne wrote: > Hi Matthias, > > On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote: > > This is the same situation as in #1040477. This is an issue wrt how we > > generate the semvers. I image rust-proc-macro-crate-1 would pose the same > > problem. Quoting you from 1040477: > > Right! > > > Is the only workaround dropping Ma:same here ? > > I see very little alternatives. We must choose: > > * Do not combine M-A:same + Provides: foo + Breaks: foo. > * Fix dose/apt/dpkg to agree on what this means. > > If we were to adapt dose and apt, they's simply arrive at the conclusion > that M-A:same would not work here so that really is not what you'd want > here. This amounts to fixing dpkg to allow this very combination in the > same way that apt and dose allow it. So yeah, changing dpkg could be an > option. Ccing dpkg-devel about it. > > The first alternative means that we must not combine them at the same > time. As we very much want M-A:same, we must not have this combination > of Provides and Brekas. Keep in mind that they serve slightly different > purposes. We have Breaks + Replaces and you can only replace a real > package but Provides introduce a virtual package. In effect we're > dealing with a package that sometimes is virtual and other times is > real. We can choose different names for these uses. The real package > could be renamed and also provide the virtual facility. All of them > would now provide the virtual one as virtual only and none of them would > have the virtual name. The Breaks and Replaces would be updated to match > the real name. we discussed this in the past already around bookworm's release, but haven't fixed the debcargo side generating these. see #1040477 and #1054156 IIRC the solution was to switch to Conflicts, and maybe stop providing librust-bitflags-dev and friends (those without any semver parts in the package name) in the semver-suffix variant, right? > This may not work for the in-archive situations right now as Breaks and > Replaces may still be necessary for upgrades, but it is something that > may work in future situations of the same kind. > > In the mean time, consider that M-A:same presently is a lie. Removing it > is better than continuing to lie. It's not like we must have everything > in perfect multiarch. Even for cross compilation, we often can get away > without M-A:same by only requiring a package for the host architecture. > M-A:same is not the goal. It's a tool and way may consider using other > tools. > > Helmut >
Bug#1069687: librust-bitflags-1-dev: fails to co-install
Hi Matthias, On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote: > This is the same situation as in #1040477. This is an issue wrt how we > generate the semvers. I image rust-proc-macro-crate-1 would pose the same > problem. Quoting you from 1040477: Right! > Is the only workaround dropping Ma:same here ? I see very little alternatives. We must choose: * Do not combine M-A:same + Provides: foo + Breaks: foo. * Fix dose/apt/dpkg to agree on what this means. If we were to adapt dose and apt, they's simply arrive at the conclusion that M-A:same would not work here so that really is not what you'd want here. This amounts to fixing dpkg to allow this very combination in the same way that apt and dose allow it. So yeah, changing dpkg could be an option. Ccing dpkg-devel about it. The first alternative means that we must not combine them at the same time. As we very much want M-A:same, we must not have this combination of Provides and Brekas. Keep in mind that they serve slightly different purposes. We have Breaks + Replaces and you can only replace a real package but Provides introduce a virtual package. In effect we're dealing with a package that sometimes is virtual and other times is real. We can choose different names for these uses. The real package could be renamed and also provide the virtual facility. All of them would now provide the virtual one as virtual only and none of them would have the virtual name. The Breaks and Replaces would be updated to match the real name. This may not work for the in-archive situations right now as Breaks and Replaces may still be necessary for upgrades, but it is something that may work in future situations of the same kind. In the mean time, consider that M-A:same presently is a lie. Removing it is better than continuing to lie. It's not like we must have everything in perfect multiarch. Even for cross compilation, we often can get away without M-A:same by only requiring a package for the host architecture. M-A:same is not the goal. It's a tool and way may consider using other tools. Helmut
Bug#1069687: librust-bitflags-1-dev: fails to co-install
On Mon, 22 Apr 2024 21:01:22 +0200 Helmut Grohne wrote: > Package: librust-bitflags-1-dev > Version: 1.3.2-5+b1 > Severity: serious > Justification: causes an installation failure > > Hi, > > Attempting to install librust-bitflags-1-dev for multiple architectures > fails, because apt and dpkg disagree about how breaks and provides work. > apt thinks that self-breaks can be ignored, but dpkg thinks that since > librust-bitflags-1-dev breaks+provides librust-bitflags-1.3.2-dev it > cannot be coinstalled and gives up. You cannot combine such > breaks+provides with m-a:same. The simplest workaround here is dropping > m-a:same as it cannot be exercised anyway. > > Helmut This is the same situation as in #1040477. This is an issue wrt how we generate the semvers. I image rust-proc-macro-crate-1 would pose the same problem. Quoting you from 1040477: A very simple workaround from my pov would be temporarily removing Multi-Arch: same. Of course that would make the package unavailable to cross compilation, but on the flip side, it already is. After dropping Multi-Arch: same, dose would no longer consider solutions involving coinstallations of it and archive testing could continue. Failing that, the only way I see is blacklisting the package in crossqa, but then I'd probably forget about it and it would also be surprising in the diagnostics as crossqa would always tell that this package does not exist. I prefer having you work around the issue. A simple upload dropping M-A:same removes the worst of pain and gives us time to work on a generic solution. Do you agree? Is the only workaround dropping Ma:same here ? Unfortunately we need the semvers (but try to keep them to a minimum). CC'd Fabian since he is a bit more knowledgable than me here. best, -- Matthias Geiger Debian Maintainer
Bug#1069687: librust-bitflags-1-dev: fails to co-install
Package: librust-bitflags-1-dev Version: 1.3.2-5+b1 Severity: serious Justification: causes an installation failure Hi, Attempting to install librust-bitflags-1-dev for multiple architectures fails, because apt and dpkg disagree about how breaks and provides work. apt thinks that self-breaks can be ignored, but dpkg thinks that since librust-bitflags-1-dev breaks+provides librust-bitflags-1.3.2-dev it cannot be coinstalled and gives up. You cannot combine such breaks+provides with m-a:same. The simplest workaround here is dropping m-a:same as it cannot be exercised anyway. Helmut
