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
>