dpkg 1.19.0.5ubuntu2.2 build did not recreate 'configure' file, losing changes in 'configure.ac'
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dpkg (Debian) |
Fix Released
|
Unknown
|
|||
dpkg (Ubuntu) |
Fix Released
|
Medium
|
Dan Streetman | ||
Xenial |
Won't Fix
|
Medium
|
Unassigned | ||
Bionic |
Fix Released
|
Medium
|
Dan Streetman | ||
Disco |
Won't Fix
|
Medium
|
Dan Streetman | ||
Eoan |
Fix Released
|
Medium
|
Dan Streetman |
Bug Description
[impact]
dpkg at version 1.19.0.5ubuntu2 had support for zstd added:
https:/
part of that change was to update the 'configure.ac' file with zstd support, e.g.:
http://
note that the 'configure' file was not updated - which *should* be ok, as it should be recreated from the 'configure.ac' file during build. For the build of that version and the next (1.19.0.
However at version 1.19.0.5ubuntu2.2, the 'configure' file was not recreated during build. Thus, dpkg was not built linked against libzstd.
This regresses the ability of dpkg to uncompress zstd-compressed packages, unless the zstd utility is installed on the local system. Since dpkg does not list the zstd package as a dep, it may not be installed on all users' systems who want to install a zstd-compressed package.
[test case]
on bionic system:
$ sudo apt install ubuntu-dev-tools
$ pull-lp-source dpkg 1.19.0.5ubuntu2.2
$ cd dpkg-1.
$ sudo apt build-dep .
$ dpkg-buildpackage
and verify if dpkg-deb is linked against libzstd:
$ ldd build-tree/
or extract it from the deb itself and check:
$ dpkg-deb -x ../dpkg_
$ ldd ../deb-
simply touching the 'configure.ac' file (to bring its timestamp newer than the 'configure' file) causes the build to work correctly:
$ mkdir no-touch
$ cd no-touch
$ dpkg-source -x ~/dpkg_
$ cd dpkg-1.
$ dpkg-buildpackage
$ ldd build-tree/
$
$ mkdir touch
$ cd touch
$ dpkg-source -x ~/dpkg_
$ cd dpkg-1.
$ touch configure.ac
$ dpkg-buildpackage
$ ldd build-tree/
libzstd.so.1 => /usr/lib/
[regression potential]
this forces autoreconf to be run for each build, which may add some small amount of time to the build. Other than that, the regression potential seems small, since autoreconf should be getting run for each build, and was for most (but not all) builds. Any regression would almost certainly involve a failure to build the package, or a failure to pick up new configure.ac changes correctly.
[other info]
this might not be an issue specifically with dpkg itself, it could be an issue with debhelper and other tooling that is responsible for calling autoconf or autoreconf during build. Or possibly a problem with the dpkg debian/rules or other related build config.
Or, simply including the 'configure' file in the package source might be considered a bug, since it's an intermediate build file that really shouldn't be included. However, it's included in many source packages, including in debian, and removing it from all of them seems unlikely and/or unwieldy. Additionally, for "normal" packages that use quilt (i.e., aren't native), any changes to the 'configure.ac' file would be done with a patch, meaning the pre-build process would always make the 'configure.ac' file newer than the 'configure' file.
Maybe for native packages, autoconf/autoreconf should always be called with -f, or maybe the 'configure' file should be removed from native packages.
description: | updated |
Changed in dpkg (Ubuntu Xenial): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in dpkg (Ubuntu Bionic): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in dpkg (Ubuntu Disco): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in dpkg (Ubuntu Eoan): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in dpkg (Ubuntu Disco): | |
importance: | Undecided → Medium |
Changed in dpkg (Ubuntu Eoan): | |
importance: | Undecided → Medium |
Changed in dpkg (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in dpkg (Ubuntu Disco): | |
status: | New → In Progress |
Changed in dpkg (Ubuntu Xenial): | |
status: | New → In Progress |
Changed in dpkg (Ubuntu Bionic): | |
importance: | Undecided → Medium |
status: | New → In Progress |
Changed in dpkg (Ubuntu Eoan): | |
status: | New → In Progress |
Changed in dpkg (Debian): | |
status: | Unknown → New |
tags: | added: sts |
Changed in dpkg (Debian): | |
status: | New → Fix Committed |
Changed in dpkg (Debian): | |
status: | Fix Committed → Fix Released |
After discussion with cjwatson in #ubuntu-devel, it looks like this is just a dpkg-specific packaging/ build-rules issue; by default, packages will use dh_autoreconf, which will call autoreconf -f to force (re)creation of the configure file. The dpkg package has its own debian/rules call to autoreconf, however, and it doesn't pass -f.
This has been fixed (maybe unintentionally) upstream by commit c72f539b979a0c8 647d2a6c62ee455 65cd243b3d which moves the call to autoreconf into an 'autogen' file, but also more importantly changes the call from 'autoreconf -v -i' to 'autoreconf -f -i'.