On Wed, 2020-07-01 at 18:14 +0200, Helmut Grohne wrote:
> 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.Nice! For some reason I thought only Build-Depends* supported profiles. TIL. > > 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. This is how upstream generates the pkg-config files for all components of util-linux - and it's how most libraries with optional features that I've come across do as well. If a feature is not built, and thus the binary does not link to the library, the dependency is not listed in pkg-config. And to me it would appear the correct thing to do - the point of pkg-config is to list what is needed to link against that library, not a hypotethical version with everything enabled - so I don't see upstream changing that any time soon. For libmount for example you get the exact same result w.r.t. libselinux. > > 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 As far as I can see in the repo on Salsa it's already been reverted, and waiting for some binary-new to be processed before upload. I'll likely provide a backported patch as soon as the PR is merged - I'd really like to get more stress-test under way long before the bullseye freeze. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
