Hi Luca,
On Wed, Jul 01, 2020 at 04:42:14PM +0100, Luca Boccassi wrote:
> The dependency is hard-coded right now, but as far as I can see it
> doesn't have to be - it could be generated at build time, depending on
> the stage. This could be done immediately as far as I can see - what
> about something like the following in d/rules:
>
> ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
> ...
> else
> LIBMOUNT_DEPENDS=libcrypsetup-dev
> ...
> endif
> ...
> override_dh_gencontrol:
> dh_gencontrol -- -V"libmount-dev:Depends=$(LIBMOUNT_DEPENDS)"
>
>
> and ${libmount-dev:Depends} in d/control instead of the hard-coded dep.
On a technical level, you can achieve the same effect by writing
Depends: libcryptsetup-dev <!stage1>
in debian/control. dpkg will evaluate the profile restriction at build
time. The question is not how to suppress the dependency, but whether
doing so is correct.
> The dependency is only needed if the pkg-config file Requires.private
> mentions libcrypsetup, which won't be the case in a stage1-built
> package.
This doesn't look right to me. If libmoun-dev's pkg-config file lists
libcrypsetup, then it should do so unconditionally. Otherwise you get
two different libmount-dev that are slightly API-incompatible. Reducing
functionality is ok, but you need to change the binary package name in
such cases. Compare hurd-dev vs hurd-headers-dev. hurd-headers-dev kinda
is a subset of hurd-dev and not built by default. In a regular build,
hurd-dev simply provides hurd-headers-dev.
For libmount-dev that'd likely amount to providing something like
libmount+dm-verity-dev and somehow ensuring that anyone who needs the
dm-verity feature depends on that virtual package.
Does that make sense to you? It still makes libmount-dev unreproducible,
but it seems like we cannot have everything.
> Then in the near future, I've proposed the following changes, which
> look like will be accepted for 2.36:
> https://github.com/karelzak/util-linux/pull/1084
> That means the dependency can be removed entirely, as pkg-config will
> no longer list libcrypsetup in its Requires.private when using --with-
> cryptsetup=dlopen.
That sounds like we can quite simply solve the whole mess by waiting. We
can revert libcryptsetup now and put it back when uploading 2.36. Does
that work for you?
In the mean time, I've filed #964092, but I don't think it's going to
cut it here.
Helmut
