On Fri, 2020-07-24 at 15:19 +0200, Chris Hofstaedtler wrote: > Luca, Helmut, everyone reading at home, > > * Luca Boccassi <bl...@debian.org> [200724 15:11]: > > > PR opened at https://github.com/karelzak/util-linux/pull/1084 > > > > PR for dlopen() has been merged and it's part of the 2.36 release which > > was just uploaded to unstable, so opened another MR to enable it again > > (in dlopen mode): > > > > https://salsa.debian.org/debian/util-linux/-/merge_requests/16 > > > > Built locally and confirmed there's no linkage, and thus no dependency, > > and strace shows libcryptsetup is only loaded if one of the verity > > options is requested, so there should not be any conflict in the > > future. > > Okay, I see the PR. > > However: > > 1) Helmut, will this cause problems again for bootstrapping or is > this fine? > > 2) What exactly are we doing this for? What is the usecase for > Debian?
1) Helmut should double-check, but there's no runtime dependency of any kind (-dev package, pkg-config, linking) and the build-dep is marked as !stage1, so should all be good on that front as far as I can tell 2) it's an end-user feature for anybody (myself being one) wanting to use verity-protected volumes (integrity checks, possible signature checks) on their machines https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMVerity -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part