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

Reply via email to