Bug#964089: libmount-dev introduced a bootstrap/dependency cycle with src:cryptsetup
Source: util-linux
Version: 2.35.2-6
Severity: important
User: helmutg@debian.org
Usertags: rebootstrap
Until recently, util-linux wasn't involved with cryptsetup and we could
build it quite early. Now libmount-dev Depends on libcryptsetup-dev.
That means src:cryptsetup must be built before src:util-linux. However
libcryptsetup Build-Depends on uuid-dev, which is built from
src:util-linux. This doesn't work as is and needs more work.
Therefore, I ask you to revert the dependency on cryptsetup right now. I
acknowledge that doing so reopens #951048, but trading a wishlist bug
for an important regression seems reasonable to me. I'm not trying to
block that feature permanently, but merely gaining some time to figure
it out properly. It is important to solve this quickly as this
regression makes other problems elsewhere in essential invisible. In
doing so, they become harder to track down. Just waiting causes damage.
One thing that bothers me is that src:util-linux Build-Depends on
libcryptsetup-dev with a <!stage1> while libmount-dev unconditionally
Depends on libcryptsetup-dev.
If you don't need libcryptsetup-dev for building libmount-dev, then the
dependency should be unnecessary. However, as #963704 turned up. We do
need that dependency. Simply marking it with <!stage1> is not a good
idea. Then you have two different packages both called "libmount-dev"
with differing contents. There is no sane way to depend on libmount-dev
with dm-verity support or libmount-dev without dm-verity support. So
that's not an option.
Essentially, this means that the <!stage1> profile needs to be dropped
from the libcryptsetup-dev build dependency. That in turn causes a
direct dependency cycle with src:cryptsetup. We don't want that either.
So this doesn't work either. It's not that easy. Can you maybe shed some
light on how libmount-dev integrates with cryptsetup?
Given that util-linux has a history of being maintained with NMUs, I
intend to continue that trend barring a timely response. I'm positive
that we'll find a permanent solution in time for bullseye.
Right now, I'm going to look into cryptsetup and will try reducing its
Build-Depends to make it easier to include in architecture bootstrap.
Helmut
Reply to: