--- Begin Message ---
Source: tzdata
Version: 2021e-1
Severity: normal
Tags: patch
User: debian-dpkg@lists.debian.org
Usertags: dpkg-root-support
X-Debbugs-Cc: josch@debian.org
Hi,
when creating chroots for new architectures that are in the process of
being bootstrapped without yet having emulation support from qemu, it is
not possible to run maintainer scripts inside the foreign architecture
chroot because foreign architecture ELF binaries cannot be executed. The
solution to that problem is to run maintainer scripts from outside the
chroot and use the DPKG_ROOT environment variable to instruct the
maintainer script on which chroot to operate. By default, for normal
installations, that environment variable is set, but empty.
Apart from init-system-helpers and pam, all packages in the
Essential:yes set have support for DPKG_ROOT already. To start building
packages we also need to install build-essential. In debootstrap, the
buildd variant includes the Essential:yes packages, Priority:required
packages and build-essential. Strictly speaking, tzdata is not necessary
to start building packages as it only gets installed in the buildd
variant of debootstrap because it is Priority:required. Still, it would
be helpful to have tzdata support DPKG_ROOT because it would avoid
having to add an exception to the buildd set chosen by debootstrap.
Please consider applying the patch at the end of this mail. We tested it
in our CI environment and it produces a bit-by-bit identical chroot with
DPKG_ROOT compared to a normal installation.
https://salsa.debian.org/helmutg/dpkg-root-demo/
Since the DPKG_ROOT variable is empty on normal installations, the patch
should have no effect in the normal case.
Thanks!
cheers, josch
diff -Nru tzdata-2021e/debian/tzdata.config tzdata-2021e/debian/tzdata.config
--- tzdata-2021e/debian/tzdata.config 2021-09-29 00:38:51.000000000 +0200
+++ tzdata-2021e/debian/tzdata.config 2022-03-14 14:49:42.000000000 +0100
@@ -372,38 +372,38 @@
}
# If /etc/localtime is a link, update /etc/timezone
-if [ -L /etc/localtime ] ; then
- TIMEZONE="$(readlink /etc/localtime)"
+if [ -L "$DPKG_ROOT/etc/localtime" ] ; then
+ TIMEZONE="$(readlink "$DPKG_ROOT/etc/localtime")"
TIMEZONE="${TIMEZONE#/usr/share/zoneinfo/}"
- if [ -f "/usr/share/zoneinfo/$TIMEZONE" ] ; then
- echo ${TIMEZONE} > /etc/timezone
+ if [ -f "$DPKG_ROOT/usr/share/zoneinfo/$TIMEZONE" ] ; then
+ echo ${TIMEZONE} > "$DPKG_ROOT/etc/timezone"
fi
fi
# Read /etc/timezone
-if [ -e /etc/timezone ]; then
- TIMEZONE="$(head -n 1 /etc/timezone)"
+if [ -e "$DPKG_ROOT/etc/timezone" ]; then
+ TIMEZONE="$(head -n 1 "$DPKG_ROOT/etc/timezone")"
TIMEZONE="${TIMEZONE%% *}"
TIMEZONE="${TIMEZONE##/}"
TIMEZONE="${TIMEZONE%%/}"
TIMEZONE="$(convert_timezone $TIMEZONE)"
- if [ -f "/usr/share/zoneinfo/$TIMEZONE" ] ; then
+ if [ -f "$DPKG_ROOT/usr/share/zoneinfo/$TIMEZONE" ] ; then
AREA="${TIMEZONE%%/*}"
ZONE="${TIMEZONE#*/}"
else
- rm -f /etc/timezone
+ rm -f "$DPKG_ROOT/etc/timezone"
fi
fi
# The timezone is already configured
-if [ -e /etc/timezone ] && [ -e /etc/localtime ] ; then
+if [ -e "$DPKG_ROOT/etc/timezone" ] && [ -e "$DPKG_ROOT/etc/localtime" ] ; then
# Don't ask the user, except if he/she explicitely asked that
if [ -z "$DEBCONF_RECONFIGURE" ] ; then
db_fset tzdata/Areas seen true
db_fset tzdata/Zones/$AREA seen true
fi
# The timezone has never been configured or is falsely configured
-elif ! [ -e /etc/localtime ] || [ -n "$DEBCONF_RECONFIGURE" ] ; then
+elif ! [ -e "$DPKG_ROOT/etc/localtime" ] || [ -n "$DEBCONF_RECONFIGURE" ] ; then
if [ -z "$AREA" ] || [ -z "$ZONE" ] ; then
RET=""
db_get tzdata/Areas || true
@@ -421,7 +421,7 @@
ZONE="UTC"
fi
- echo "$AREA/$ZONE" > /etc/timezone
+ echo "$AREA/$ZONE" > "$DPKG_ROOT/etc/timezone"
fi
db_fset tzdata/Areas seen false
db_fset tzdata/Zones/$AREA seen false
diff -Nru tzdata-2021e/debian/tzdata.postinst tzdata-2021e/debian/tzdata.postinst
--- tzdata-2021e/debian/tzdata.postinst 2018-07-10 00:46:15.000000000 +0200
+++ tzdata-2021e/debian/tzdata.postinst 2022-03-14 14:49:40.000000000 +0100
@@ -12,7 +12,7 @@
if [ "$1" = configure ]; then
# If the user prefers to manage the time zone by itself, let him doing that.
- if ! [ -e /etc/timezone ] && [ -z "$DEBCONF_RECONFIGURE" ] ; then
+ if ! [ -e "$DPKG_ROOT/etc/timezone" ] && [ -z "$DEBCONF_RECONFIGURE" ] ; then
db_stop
echo
echo "User defined time zone, leaving /etc/localtime unchanged."
@@ -26,10 +26,10 @@
db_stop
# Update the time zone
- echo $AREA/$ZONE > /etc/timezone
- ln -nsf /usr/share/zoneinfo/$AREA/$ZONE /etc/localtime.dpkg-new && \
- mv -f /etc/localtime.dpkg-new /etc/localtime
- which restorecon >/dev/null 2>&1 && restorecon /etc/localtime
+ echo $AREA/$ZONE > "$DPKG_ROOT/etc/timezone"
+ ln -nsf /usr/share/zoneinfo/$AREA/$ZONE "$DPKG_ROOT/etc/localtime.dpkg-new" && \
+ mv -f "$DPKG_ROOT/etc/localtime.dpkg-new" "$DPKG_ROOT/etc/localtime"
+ which restorecon >/dev/null 2>&1 && restorecon "$DPKG_ROOT/etc/localtime"
echo
echo "Current default time zone: '$AREA/$ZONE'"
--- End Message ---
--- Begin Message ---
Version: 2022a-1
On 2022-03-16 11:20, Johannes Schauer Marin Rodrigues wrote:
> Source: tzdata
> Version: 2021e-1
> Severity: normal
> Tags: patch
> User: debian-dpkg@lists.debian.org
> Usertags: dpkg-root-support
> X-Debbugs-Cc: josch@debian.org
>
> Hi,
>
> when creating chroots for new architectures that are in the process of
> being bootstrapped without yet having emulation support from qemu, it is
> not possible to run maintainer scripts inside the foreign architecture
> chroot because foreign architecture ELF binaries cannot be executed. The
> solution to that problem is to run maintainer scripts from outside the
> chroot and use the DPKG_ROOT environment variable to instruct the
> maintainer script on which chroot to operate. By default, for normal
> installations, that environment variable is set, but empty.
>
> Apart from init-system-helpers and pam, all packages in the
> Essential:yes set have support for DPKG_ROOT already. To start building
> packages we also need to install build-essential. In debootstrap, the
> buildd variant includes the Essential:yes packages, Priority:required
> packages and build-essential. Strictly speaking, tzdata is not necessary
> to start building packages as it only gets installed in the buildd
> variant of debootstrap because it is Priority:required. Still, it would
> be helpful to have tzdata support DPKG_ROOT because it would avoid
> having to add an exception to the buildd set chosen by debootstrap.
>
> Please consider applying the patch at the end of this mail. We tested it
> in our CI environment and it produces a bit-by-bit identical chroot with
> DPKG_ROOT compared to a normal installation.
>
> https://salsa.debian.org/helmutg/dpkg-root-demo/
>
> Since the DPKG_ROOT variable is empty on normal installations, the patch
> should have no effect in the normal case.
>
I have merged this patch in version 2022a-1, but forgot to add the bug
number to the changelog. Closing the bug manually.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
--- End Message ---