[PATCH 0/9] LP: #1912803 -- autogenerate Nvidia rules/control

[Andy Whitcroft]

Changing the version of an Nvidia package is pretty straight forward.  We
change the version in debian/dkms-versions in the *:linux (main) packages and
this propogates to each derivative main kernel and from there into the
dependant linux-restricted-modules* (lrm) package.  However, when we wish to
add a new 'series' such as 460 or 460-server things are much more complex.
Firstly, we add a new dkms-versions entry for the series.  We then add a pair
of new stanzas to to the kernel packaging in the *:linux main packages (not
overly onerous).  Finally we must add new stanzas and package definitions to
every single linux-restricted-modules* package individually (very very
onerous).  This email details some packaging improvements I am proposing for
the main and lrm packages.

For the main package we want to build signatures for all nvidia versions
specified.  Here I am removing the per-series rules and version lookup and
replacing it with iterative make rules.

For the lrm packages the intent is that the entire contents of lrm package is
specified by the contents of two configurations; debian/dkms-versions which
comes to lrm via its main package from the appropriate *:linux main package,
and from debian/package.config which carries any per lrm configuration (mostly
the architectures and flavours supported by that lrm package).  The lrm rules
and control are generated en-toto from these two configuration files at package
clean time.

With these in place we are able to add or remove (and transition) a version
via modifications to the dkms-versions file in the *:linux main package.
All other change propogates automatically into the generated rules.

In order to handle sign-only[1] nvidia builds and to allow control over
creation of appropriate transitional packags when deprecating series the
dkms-versions format is extended for nvidia entries.  Taking the current
groovy:linux dkms-versions file as an example:

  zfs-linux 0.8.4-1ubuntu11.1
  nvidia-graphics-drivers-390 390.141-0ubuntu0.20.10.1
  nvidia-graphics-drivers-435 435.21-0ubuntu8 signonly
  nvidia-graphics-drivers-450 450.102.04-0ubuntu0.20.10.1 transition=nvidia-graphics-drivers-440
  nvidia-graphics-drivers-455 455.45.01-0ubuntu0.20.10.1 signonly
  nvidia-graphics-drivers-460 460.32.03-0ubuntu0.20.10.1 transition=nvidia-graphics-drivers-455 transition=nvidia-graphics-drivers-435
  nvidia-graphics-drivers-418-server 418.181.07-0ubuntu0.20.10.1
  nvidia-graphics-drivers-440-server 440.95.01-0ubuntu2 signonly
  nvidia-graphics-drivers-450-server 450.102.04-0ubuntu0.20.10.1 transition=nvidia-graphics-drivers-440-server

The new directives are added in fields three onwards.  Currently two
directives are supported:

  - signonly -- which indicates that the main package should build and extract
    a signature from that nvidia series, but that lrm should not build the
    package, and
  - transition=<series package> -- which indicates that the older series should
    generate transitional packages pointing to this nvidia series.

Additionally each lrm package will be configured via debian/package.config
which contains (generally static) information such as the architectures and
flavours for which we wish to generate packages.  For example for
focal:linux-hwe-5.8 we have:

  build generic amd64
  build lowlatency amd64
  option desktop
  option server
  transitional 440-oem-20.04 450-generic amd64
  transitional 450-oem-20.04 450-generic amd64

This indicates we build on amd64 for generic and lowlatency flavours, we build
both desktop (440, 450 etc) and server (450-server etc) series, and finally
indicates that there are some addhoc transitionals needed to handle upgrades
from the oem package.

Currently three directives are supported:

  - build <flavour> <arch list> -- defines the architectures on which we should
    generate packages for this flavour.
  - option desktop|server -- defines whether this package generates desktop and
    server series respectivly.
  - transitional <from> <to> <arch list> -- defines the architectures on which
    transitional packages are needed for an adhoc transition.

The changes for the main packages consist of two patches for each
series; a change to debian/rules* to implement the dynamic rules, and a
patch for debian/dkms-versions which adds the additional annotations.  I
include the rules change for the groovy main package as an example, the
dkms-versions is as above (and will have to be regenerated at
application time).

The changes for the lrm packages are more complex as each lrm package must be
configured indicating the flavours and architecures, and pulling out any local
transitionals.  I am including the patch kit[2] as applied to
grooy:linux-restricted-modules package.  This conversion has been scripted to
simplify application.  I am therefore including this as a sampler for review
and and, but proposed to apply the lrm changes programatically.

It should be noted that a pleasant outcome from this conversion is that once
converted to this form all of the core LRM content is generated by a single
common rules.gen script which can augmented and be updated via a cranky fix.

-apw

[1] signonly nvidia builds are used when transitioning from one series to
another, but we might wish to drop back if testing fails.  There we can build a
signature in the old nvidia series, but not package or ship those in lrm.

[2]
 Andy Whitcroft (9):
  UBUNTU: [Packaging] generate nvidia version mappings at clean time
  UBUNTU: [Packaging] generate nvidia version mappings at clean time -- add transitionals
  UBUNTU: [Packaging] generate nvidia version mappings at clean time -- handle Build-Depends
  UBUNTU: [Packaging] generate nvidia version mappings at clean time -- use Build-Depends-Arch
  UBUNTU: [Packaging] generate nvidia version mappings at clean time -- add signonly
  UBUNTU: [Packaging] generate nvidia version mappings at clean time -- handle +21.04.1
  UBUNTU: [Packaging] generate nvidia version mappings at clean time -- add options
  UBUNTU: [Packaging] generate nvidia version mappings at clean time -- handle old dkms-build API
  UBUNTU: [Packaging] generate nvidia version mappings at clean time -- add suppress support

 debian/control.common                    |   6 +-
 debian/control.d/meta-nvidia             | 148 ---------------
 debian/control.d/migrate-nvidia-435      |  13 --
 debian/control.d/migrate-nvidia-440      |  13 --
 debian/control.d/nvidia                  | 227 -----------------------
 debian/control.d/transitionals-oem-20.04 |  13 --
 debian/dkms-versions                     |   5 +-
 debian/package.config                    |   4 +
 debian/rules                             | 194 +------------------
 debian/rules.in                          | 139 ++++++++++++++
 debian/scripts/gen-rules                 | 173 +++++++++++++++++
 debian/source/options                    |   3 +
 12 files changed, 327 insertions(+), 611 deletions(-)
 delete mode 100644 debian/control.d/meta-nvidia
 delete mode 100644 debian/control.d/migrate-nvidia-435
 delete mode 100644 debian/control.d/migrate-nvidia-440
 delete mode 100644 debian/control.d/nvidia
 delete mode 100644 debian/control.d/transitionals-oem-20.04
 create mode 100644 debian/package.config
 create mode 100755 debian/rules.in
 create mode 100755 debian/scripts/gen-rules