--- Begin Message ---
Package: udhcpc
Version: 1:1.36.1-6~exp.1
Severity: normal
User: helmutg@debian.org
Usertags: dep17p7
Hi Chris,
thanks for sitting down with me and doing this /usr-move. We aimed to be
careful and upload to experimental. Now dumat doesn't like your upload.
I'm trying to figure out why and whether this is an analyzer bug or a
real problem, so please do not move busybox to unstable for the time
bing.
What follows is details that you may skip entirely, but figured I better
write them down for my future self. So dumat figured that udhcpc is
Multi-Arch: same in bookworm and /sbin/udhcpc is a shared file. Then the
experimental package contains /usr/sbin/udhcpc. In theory, this could
result in a loss scenario, because you can install udhcpc for two
architecture in bookworm, dpkg --unpack the experimental one for one
architecture and then dpkg --remove the other. While you can unpack
udhcpc for two architectures, configuring it does not work out, because
it depends on busybox, which happens to implied to be Multi-Arch: no and
apt would never consider a solution where you'd have to coinstall
udhcpc. Also udhcpc was changed to an Architecture: all package later
and that also makes the issue unreproducible. In theory, the detector
should have noticed that the experimental package is not coinstallable
with itself and therefore the alleged problem cannot be exercised.
I think the latter is an analyzer bug and should have prevented the
issue from being displayed. In the mean time, please avoid uploading
this to unstable. I'll either close this bug or upgrade it to rc once I
have a better understanding of what's going on.
Helmut
--- End Message ---
--- Begin Message ---
Hi Chris,
TL;DR: If you don't convert udhcpc back to M-A:same and you'll be fine.
On Fri, Nov 24, 2023 at 12:27:38AM +0100, Helmut Grohne wrote:
> What follows is details that you may skip entirely, but figured I better
> write them down for my future self. So dumat figured that udhcpc is
> Multi-Arch: same in bookworm and /sbin/udhcpc is a shared file. Then the
> experimental package contains /usr/sbin/udhcpc. In theory, this could
> result in a loss scenario, because you can install udhcpc for two
> architecture in bookworm, dpkg --unpack the experimental one for one
> architecture and then dpkg --remove the other. While you can unpack
> udhcpc for two architectures, configuring it does not work out, because
> it depends on busybox, which happens to implied to be Multi-Arch: no and
> apt would never consider a solution where you'd have to coinstall
> udhcpc. Also udhcpc was changed to an Architecture: all package later
> and that also makes the issue unreproducible. In theory, the detector
> should have noticed that the experimental package is not coinstallable
> with itself and therefore the alleged problem cannot be exercised.
You've triggered a quite unique situation. The analyzer is correct about
it and the situation is fine. It was merely me being confused. :)
So yes, bookworm's udhcpc is m-a:same and performing the /usr-move runs
a theoretical risk of triggering the DEP17 P7 problem. As explained in
my earlier mail, you cannot actually trigger this for two reasons:
* For one thing, udhcpc depends on busybox, which is implicitly m-a:no
and therefore you cannot actually install two udhcpc concurrently.
For technical correctness, you can dpkg --unpack them (leaving
dependencies unsatisfied) and this would bear a risk, but apt never
does this.
* The trixie/sid/experimental packages have changed udhcpc to
Architecture:all plus implied Multi-Arch:no. As a consequence, dpkg
will not allow you to unpack the new udhcpc before removing all but
one instance of udhcpc. This restriction reliably prevents the
problem.
Now why did it show up in the dumat report? What I didn't read precisely
was that it did not predict a loss scenario, but a "pre-loss" scenario.
This is an advance warning about the P7 situation being close. In most
cases, where this is emitted, a dh_movetousr is the missing piece to
realize the problem and having this warning is a nice indicator to see
how much problems we will get. In this case, the missing piece is adding
back Multi-Arch: same to udhcpc. I do not see this happening anytime
soon, so unlike most pre-loss scenarios, this one is very unlikely to
become a real one.
I know the hinter (that I wrote %-) told you to add Multi-Arch: same and
that the janitor applied this. While the hint wasn't technically wrong,
it was not useful in this situation and no longer is being emitted since
quite a while, so even if you were to change back to Architecture: any,
the hinter would not be asking you to add Multi-Arch: same anymore.
On the dumat side, I have renamed the tag to reduce the confusion of my
future self:
https://salsa.debian.org/helmutg/dumat/-/commit/adcb35fc9c5b7afe1e0f7be6ffebe56bede3f5ac
So this situation really is fine with the caveat that udhcpc should not
go back to Architecture: any + Multi-Arch: same before trixie is
released. Since this pre-issue is an upgrade problem, that caveat stops
applying thereafter.
Thanks for bearing with me. Let me know if the change results in any
unforeseen problems after migrating it to sid.
Helmut
--- End Message ---