Bug#884711: stretch-pu: package dpdk/16.11.4-1+deb9u1

[Julien Cristau <jcristau@debian.org>]

Control: tag -1 moreinfo

Hi Luca,

On Mon, Dec 18, 2017 at 14:46:04 +0000, Luca Boccassi wrote:

> DPDK maintains LTS branches upstream for 2 years [1]. This is covered
> by regressions tests from Intel and AT&T on various networking hardware
> and virtualized environments.These tests are run to validate the
> release branch before tagging a new version. Other hardware vendors
> regularly test these LTS versions too. They are also used by other
> distros such as RedHat and Ubuntu.
> Only bug fixes that affect that release branch, and that have already
> been merged in the mainline, are allowed. No API/ABI changes of any
> kind are allowed. Full changelog can be found at the bottom of the
> release notes [2].
> Each major mainline release is followed by an LTS branch release, where
> the relevant bug fixes are backported, so there are usually 4 bugfix
> LTS releases per year. There are usually between 10 and 100 patches
> backported per release.
> 
> Stretch shipped with the first release of 16.11. Since then, there have
> been 4 bugfix LTS releases, up to 16.11.4 a few days ago.
> We have uploaded them to unstable/testing/stretch-backports.
> 
> We would like to take advantage of the upstream LTS maintenance and
> push these point releases to Stretch.
> 
> Attached is the full debdiff. I can provide a debdiff for each
> individual point release between 16.11 and 16.11.4 if required.
> There is only one change in dependency, python-elftools was demoted
> from Recommends to Suggests as it's not useful in most cases. I think
> this change is fine but can remove it if asked.
> 
> Patches to fix bugs reported on Ubuntu, and to make the build
> reproducible, are also included. I can remove them if asked.
> 
> The changelog is inlined at the bottom.
> 
> Although the main users are Debian users with custom software, there is
> a reverse build-dep in Stretch as well, collectd. It works fine with
> the new LTS version.
> 
Thanks for the detailed explanation, that helps.

A few comments:
- I'd rather do without the changes in debian/control
- likewise init script, pkg-config file (unless there's an explanation)
- the above doesn't seem to address the changes in debian/patches/, can
  you detail the reason behind each of those?
- I think from our perspective the reproducibility changes are adding
  more risk than anything else, and normally not appropriate for stable
- the change in prep-modules, generating dependencies on the exact version
  of linux-image rather than the ABI (probably with ">=" the build
  version), looks wrong.  I don't know if/how that is used by the package
  though.
- the debian/rules changes introduce noise, so if that can be trimmed
  down it would be welcome
- I can't speak to the upstream changes, but no objection in principle
  if that stuff is tested as you describe.  Is any of the LTS branch
  testing done in a Debian stable environment, either by upstream, you,
  or some other users of this code?

Cheers,
Julien