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 >