XPost: linux.debian.bugs.dist
From:
guillem@debian.org
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
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)