[Bug 1842947] Re: dpkg 1.19.0.5ubuntu2.2 build did not recreate 'configure' file, losing changes in 'configure.ac'

[Robie Basak]

On Fri, Dec 13, 2019 at 01:58:19PM -0000, Dan Streetman wrote:
> > I don't see a specific problem it would fix, nor do I see a significant future 
> > risk of a problem being exposed.
> 
> the [test case] section shows how this problem can manifest; and this
> *actually did happen* with the bionic build, as explained in [impact]
> section.

Because of an attempt at a feature addition, right? And that was picked
up at verification time? I don't think we expect to make any further
feature additions to Xenial now?

> I honestly don't understand the resistance to what seems completely safe
> and correct to me, nor do I understand if my [impact] and [test case]
> sections are unclear, so maybe I'm missing something in @racb's logic.

"We never assume that any change, no matter how obvious, is completely
free of regression risk." --https://wiki.ubuntu.com/StableReleaseUpdates

Changing the build time configuration of a package seems ripe for
unexpected and unrelated regressions to me. Further, dpkg is a critical
package and a regression in it may not be easy for users to resolve just
by us releasing a further update.

I suppose we could stage a change in proposed, because we do now have
that mechanism, but depending on the nature of a future patch, taking
the risk on this change might be unnecessary in the future so I don't
think that would mitigate my concern here.

Your change also seems in principle "completely safe and correct" to me,
but take a look at recent 'regression-update' tagged bugs to see how
other SRUs that seemed "completely safe and correct" resulted in
regressions.

Carefully weighing up the benefits and the risks and reaching a
different conclusion is perfectly fine. It concerns me that rather than
doing this you seem to be denying the existence of any possibility of
regression risk just because it seems "completely safe and correct" at
the moment. That's not how regression risk works.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dpkg in Ubuntu.
https://bugs.launchpad.net/bugs/1842947

Title:
  dpkg 1.19.0.5ubuntu2.2 build did not recreate 'configure' file, losing
  changes in 'configure.ac'

Status in dpkg package in Ubuntu:
  Fix Released
Status in dpkg source package in Xenial:
  In Progress
Status in dpkg source package in Bionic:
  Fix Released
Status in dpkg source package in Disco:
  Fix Committed
Status in dpkg source package in Eoan:
  Fix Released
Status in dpkg package in Debian:
  Fix Committed

Bug description:
  [impact]

  dpkg at version 1.19.0.5ubuntu2 had support for zstd added:
  https://launchpad.net/ubuntu/+source/dpkg/1.19.0.5ubuntu2

  part of that change was to update the 'configure.ac' file with zstd support, e.g.:
  http://launchpadlibrarian.net/366237303/dpkg_1.19.0.5ubuntu1_1.19.0.5ubuntu2.diff.gz

  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.5ubuntu2.1), the
  'configure' file was correctly recreated during build.

  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.19.0.5ubuntu2.2/
  $ sudo apt build-dep .
  $ dpkg-buildpackage

  and verify if dpkg-deb is linked against libzstd:
  $ ldd build-tree/dpkg-deb/dpkg-deb | grep zstd

  or extract it from the deb itself and check:
  $ dpkg-deb -x ../dpkg_1.19.0.5ubuntu2.2_amd64.deb ../deb-files
  $ ldd ../deb-files/usr/bin/dpkg-deb | grep zstd

  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_1.19.0.5ubuntu2.2.dsc
  $ cd dpkg-1.19.0.5ubuntu2.2/
  $ dpkg-buildpackage
  $ ldd build-tree/dpkg-deb/dpkg-deb | grep zstd
  $

  $ mkdir touch
  $ cd touch
  $ dpkg-source -x ~/dpkg_1.19.0.5ubuntu2.2.dsc
  $ cd dpkg-1.19.0.5ubuntu2.2/
  $ touch configure.ac
  $ dpkg-buildpackage
  $ ldd build-tree/dpkg-deb/dpkg-deb | grep zstd
   libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f8c1d8af000)

  [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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1842947/+subscriptions