Hi Aurelien,

On Tue, Apr 14, 2020 at 05:49:38PM +0200, Helmut Grohne wrote:
> Yes, please. Is there anything blocking this? Without support in glibc,
> moving forward is a little difficult. Can you include it soonish?

I pinged Aurelien on IRC about this. Let me summarize your answer here:

 * The relevant maintainer scripts are fragile. Experience has shown
   that every time one touches them they break. They should be
 * Does the patch actually make libc6 work the way it advertises?
 * What about libc-bin?
 * Why not move forward with more testing of more packages before
   applying this patch?

Yes, that makes sense. Let me give a partial answer already.

I've performed a number of upgrades from unstable to patched libc
packages in buildd-like environments now. The coverage is limited.

I've set up a little testing lab to build patched versions of
base-files, bash, coreutils, debhelper, debianutils, dpkg, glibc, shadow
and util-linux. When installing subsets of essential using these patched
packages, few packages fail to install. The failures are base-files,
base-passwd, bash, dash, debconf, libc-bin, libpam-modules-bin,
libpam-modules, libpam0g, login, mawk, sysvinit-utils, and util-linux.
The majority of failures is due to missing patches for debconf. libc-bin
is notable here as it will need changes to ldconfig to support this use
case. However, very few packages depend on libc-bin. Therefore, I think
solving libc-bin at a later time is reasonable.

Small steps have been made in various packages:
Guillem Jover resumed up work on dpkg-maintscript-helper and

In any case, I think that this patch does indeed make the library (not
libc-bin) work for DPKG_ROOT and I'd prefer libc-bin to be handled in a
separate issue.

So yeah, we can move forward without this being merged if we really
want. Questioning whether this patch blocks progress was a useful thing
to do. There will be more fixes.


Reply via email to