Bug#910685: glibc: please support DPKG_ROOT

2020-04-19 Thread Helmut Grohne
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
   well-tested.
 * 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:
https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/4
https://salsa.debian.org/debian/shadow/-/merge_requests/10
https://salsa.debian.org/debian/shadow/-/merge_requests/11
https://salsa.debian.org/debian/debianutils/-/merge_requests/5
Guillem Jover resumed up work on dpkg-maintscript-helper and
update-alternatives.

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.

Helmut



Bug#910685: glibc: please support DPKG_ROOT

2020-04-14 Thread Helmut Grohne
On Tue, Oct 09, 2018 at 10:09:57PM +0200, Johannes 'josch' Schauer wrote:
> Currently in Debian sid, there are 57 packages that need to be installed
> for the whole Essential:yes set. Most of them Depend (directly or
> indirectly) on libc6. Attached patch adds $DPKG_ROOT to a couple of
> places of the preinst and postinst of libc6 and that will make 37 of
> these 57 install without problems. The patch adds $DPKG_ROOT in more
> places than strictly necessary for just installing packages. For example
> I didn't test the upgrade scenario. If you like, I can prepare a smaller
> patch with only the code paths that I tested.

I think that your approach is not ideal. Much of the code in the libc
scripts is for ensuring that a system is not bricked and that services
continue to work after a libc upgrade. When working with the chrootless
mode, we cannot assume that the running kernel version or other aspects
are relevant to the chroot at hand. In this case, it is much better to
skip the relevant code entirely. Doing so has the additional benefit of
not using debconf at all. When running in chrootless mode, there cannot
be any services running, because they'd have to be chrooted. So we can
simply skip all those checks. The patch becomes quite a bit simpler.

> It would be nice if you could consider applying attached patch because
> it is required for the majority of packages in the Essential:yes set to
> be successfully installed with the --force-script-chrootless mode.
> 
> To test you can run:
> 
> dpkg --root "$target" --log "$target/var/log/dpkg.log" 
> --force-script-chrootless -i libc6_2.27-6.1_amd64.deb

Yes, please. Is there anything blocking this? Without support in glibc,
moving forward is a little difficult. Can you include it soonish?

Helmut
diff --minimal -Nru glibc-2.30/debian/changelog glibc-2.30/debian/changelog
--- glibc-2.30/debian/changelog 2020-03-25 13:56:56.0 +0100
+++ glibc-2.30/debian/changelog 2020-04-14 17:39:34.0 +0200
@@ -1,3 +1,10 @@
+glibc (2.30-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Initial, minimal support for DPKG_ROOT. (Closes: #910685)
+
+ -- Helmut Grohne   Tue, 14 Apr 2020 17:39:34 +0200
+
 glibc (2.30-4) unstable; urgency=medium
 
   [ Aurelien Jarno ]
diff --minimal -Nru glibc-2.30/debian/debhelper.in/libc.postinst 
glibc-2.30/debian/debhelper.in/libc.postinst
--- glibc-2.30/debian/debhelper.in/libc.postinst2020-03-25 
13:36:06.0 +0100
+++ glibc-2.30/debian/debhelper.in/libc.postinst2020-04-14 
17:36:49.0 +0200
@@ -17,11 +17,14 @@
 if [ "$type" = "configure" ]
 then
 # We don't use a registry anymore, remove the old file
-rm -f /etc/ld.so.hwcappkgs
+rm -f "$DPKG_ROOT/etc/ld.so.hwcappkgs"
  
 # /etc/ld.so.nohwcap code:
 __NOHWCAP__
+fi
 
+if [ "$type" = configure -a -z "$DPKG_ROOT" ]
+then
 # Load debconf module if available
 if [ -f /usr/share/debconf/confmodule ] ; then
. /usr/share/debconf/confmodule
diff --minimal -Nru glibc-2.30/debian/debhelper.in/libc.preinst 
glibc-2.30/debian/debhelper.in/libc.preinst
--- glibc-2.30/debian/debhelper.in/libc.preinst 2020-03-25 13:38:38.0 
+0100
+++ glibc-2.30/debian/debhelper.in/libc.preinst 2020-04-14 17:38:54.0 
+0200
@@ -19,7 +19,7 @@
 test $verA -$2 $verB
 }
 
-if [ "$type" != abort-upgrade ]
+if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ]
 then
 # Load debconf module if available and usable
 if [ -f /usr/share/debconf/confmodule ] && \
@@ -148,7 +148,7 @@
 fi
 fi
 
-if [ "$type" = upgrade ]
+if [ "$type" = upgrade -a -z "$DPKG_ROOT" ]
 then
 if [ -n "$preversion" ] && [ -x "$(which ischroot)" ] && ! ischroot; then
# NSS authentication trouble guard
@@ -246,8 +246,8 @@
# unconditionally wipe ld.so.cache on major version upgrades; this
# makes those upgrades a bit slower, but is less error-prone than
# hoping we notice every time the cache format is changed upstream
-   rm -f /etc/ld.so.cache
-   rm -f /var/cache/ldconfig/aux-cache
+   rm -f "$DPKG_ROOT/etc/ld.so.cache"
+   rm -f "$DPKG_ROOT/var/cache/ldconfig/aux-cache"
 fi
 fi
 
diff --minimal -Nru glibc-2.30/debian/script.in/nohwcap.sh 
glibc-2.30/debian/script.in/nohwcap.sh
--- glibc-2.30/debian/script.in/nohwcap.sh  2019-08-16 12:57:33.0 
+0200
+++ glibc-2.30/debian/script.in/nohwcap.sh  2020-04-14 17:39:30.0 
+0200
@@ -18,5 +18,5 @@
 # one, we could remove /etc/ld.so.nohwcap. Otherwise, it will be removed
 # when all optimized packages are upgraded or removed.
 if [ "$all_upgraded" = yes ] ; then
-rm -f /etc/ld.so.nohwcap
+rm -f "$DPKG_ROOT/etc/ld.so.nohwcap"
 fi


Bug#910685: glibc: please support DPKG_ROOT

2018-10-09 Thread Johannes 'josch' Schauer
Source: glibc
Version: 2.27-6
Severity: wishlist
Tags: patch
Control: user debian-d...@lists.debian.org
Control: usertag -1 + dpkg-root-support

Hi,

In version 1.18.5, dpkg gained a new way for installing binary packages.
It now supports executing maintainer scripts outside the system it is
operating on. The feature is tracked at
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap. This is
relevant in two ways:
 * When running debootstrap, ordering postinsts is tricky due to the
   number of dependency loops. By executing them outside the chroot,
   some loops can be broken as utilities of the outer system can be
   used.
 * When creating chroots for foreign architectures, the utilities
   inside such chroots usually cannot be executed at all.

To support this, dpkg now unconditionally exports an environment
variable called DPKG_ROOT. It will point to the installation root with
the trailing slash stripped. That means under normal conditions, it is
empty. Since scripts are normally run under chroot(2) even when passing
--root to dpkg, it is empty in that case as well. Only when explicitly
activating the new mode, the chroot call is skipped and DPKG_ROOT can be
non-empty. It is yet unclear under what conditions this mode should be
enabled, so for the time being the only way to do so is to use
--force-script-chrootless and I stress that this is only meant for
testing.

Currently in Debian sid, there are 57 packages that need to be installed
for the whole Essential:yes set. Most of them Depend (directly or
indirectly) on libc6. Attached patch adds $DPKG_ROOT to a couple of
places of the preinst and postinst of libc6 and that will make 37 of
these 57 install without problems. The patch adds $DPKG_ROOT in more
places than strictly necessary for just installing packages. For example
I didn't test the upgrade scenario. If you like, I can prepare a smaller
patch with only the code paths that I tested.

It would be nice if you could consider applying attached patch because
it is required for the majority of packages in the Essential:yes set to
be successfully installed with the --force-script-chrootless mode.

To test you can run:

dpkg --root "$target" --log "$target/var/log/dpkg.log" 
--force-script-chrootless -i libc6_2.27-6.1_amd64.deb

Thanks!

cheers, josch
diff -Nru glibc-2.27/debian/changelog glibc-2.27/debian/changelog
--- glibc-2.27/debian/changelog 2018-09-04 21:13:02.0 +0200
+++ glibc-2.27/debian/changelog 2018-10-09 06:02:02.0 +0200
@@ -1,3 +1,10 @@
+glibc (2.27-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * support DPKG_ROOT
+
+ -- Johannes 'josch' Schauer   Tue, 09 Oct 2018 06:02:02 
+0200
+
 glibc (2.27-6) unstable; urgency=medium
 
   [ Samuel Thibault ]
diff -Nru glibc-2.27/debian/debhelper.in/libc.postinst 
glibc-2.27/debian/debhelper.in/libc.postinst
--- glibc-2.27/debian/debhelper.in/libc.postinst2018-01-06 
01:49:53.0 +0100
+++ glibc-2.27/debian/debhelper.in/libc.postinst2018-10-09 
06:02:02.0 +0200
@@ -17,14 +17,14 @@
 if [ "$type" = "configure" ]
 then
 # We don't use a registry anymore, remove the old file
-rm -f /etc/ld.so.hwcappkgs
+rm -f "$DPKG_ROOT/etc/ld.so.hwcappkgs"
  
 # /etc/ld.so.nohwcap code:
 __NOHWCAP__
 
 # Load debconf module if available
-if [ -f /usr/share/debconf/confmodule ] ; then
-   . /usr/share/debconf/confmodule
+if [ -f "$DPKG_ROOT/usr/share/debconf/confmodule" ] ; then
+   . "$DPKG_ROOT/usr/share/debconf/confmodule"
 fi
 
 if [ -n "$preversion" ] && [ -x "$(which ischroot)" ] && ! ischroot; then
@@ -41,7 +41,7 @@
__NSS_CHECK__
if [ -n "$services" ]; then
 
-   if [ -f /usr/share/debconf/confmodule ] ; then
+   if [ -f "$DPKG_ROOT/usr/share/debconf/confmodule" ] ; then
db_version 2.0
db_input critical libraries/restart-without-asking || true
db_go || true
@@ -116,7 +116,7 @@
done
echo
if [ -n "$failed" ]; then
-   if [ -f /usr/share/debconf/confmodule ] ; then
+   if [ -f "$DPKG_ROOT/usr/share/debconf/confmodule" ] ; 
then
db_fset glibc/restart-failed seen false
db_subst glibc/restart-failed services "$failed"
db_input critical glibc/restart-failed || true
@@ -140,7 +140,7 @@
fi
 # Shut down the frontend, to make sure none of the
# restarted services keep a connection open to it
-   if [ -f /usr/share/debconf/confmodule ] ; then
+   if [ -f "$DPKG_ROOT/usr/share/debconf/confmodule" ] ; then
db_stop
fi
else
@@ -156,7 +156,7 @@
 if ischroot 2>/dev/null; then
 # Don't bother trying to re-exec init from a chroot:
 TELINIT=no
-