> Please also complete this section.

sorry, forgot that, updated it

> Please could you explain, for SRU purposes, why not building dpkg
linked with libzstd is a problem for stable releases

updated impact section with explanation

** Description changed:

  [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.
  
  [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:
+ 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)
+  libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f8c1d8af000)
  
  [regression potential]
  
- TBD
+ 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 changed:

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to 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'

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

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to