[usability/consequences] "linux-image-generic" packaging structure/hierarchy feels just wrong [16.04LTS]

[Andreas Mohr]

Hello all,

background: been trying to successfully install more modern kernel versions on 16.04LTS (due to:
4.4.0 being semi-crashy on me [meta key interrupt handler race conditions!?]),
e.g. the newer linux-image-4.8.0-58-generic.

Problem seems to be that
this is NOT a correctly managed packaging dependency structure, since:
that way linux-image-extra-4.8.0-58-generic will be missing!
(which it currently strongly looks like that is the cause of
a grave i915 DP suspend/resume issue on my Dell 9010 box)


$ dpkg -s linux-image-generic
Package: linux-image-generic
Status: install ok installed
Priority: optional
Section: kernel
Installed-Size: 14
Maintainer: Ubuntu Kernel Team <kernel-team at lists.ubuntu.com>
Architecture: amd64
Source: linux-meta
Version: 4.4.0.128.134
Depends: linux-image-4.4.0-128-generic,
linux-image-extra-4.4.0-128-generic, linux-firmware, intel-microcode,
amd64-microcode
Recommends: thermald
Description: Generic Linux kernel image
 This package will always depend on the latest generic kernel image
  available.


Yeah - and any newer kernel - will fail to work!! (since
the -extra package is not inherently/automatically provided there since
such properly encapsulating/bundling meta packages are *NOT* properly provided for
*each* such kernel version)
The root cause AFAICS is that
package hierarchy is (doubly...) broken.

Instead, there likely should be
a meta package provided for *every* relevant "LTS-type" kernel
(e.g. version linux-image-4.8.0-58-generic) which then
always aggregates the usual suspects required for a particular version:
linux-image-FOO-generic
linux-image-extra-FOO-generic
linux-firmware
intel-microcode
amd64-microcode

And then have one "final-layer" meta package which
merely does the reference towards
the "currently relevant" kernel version package, i.e.
which would thus achieve to merely be
a very simple plain pointer to be switched to
the currently relevant versioned bundling package.



Also, naming "linux-image-generic" is
a thoroughly ugly same-name-yet-different-universe symmetry violation, since:
the kernel package versions each already do have
a package which is already called "generic" (*plus* the -extra package).
This despite the fact that
the "only" distinction between linux-image-generic and linux-image-FOO-generic
would sort of obviously [usability-]expected to be the *VERSION*! (yet
the merely non-versioned package name then
astonishingly happens to be very different since
it provides *all* Depends:encies, too...)
Thus, the naming of the "outermost-level" package should definitely be
something sufficiently different to that, since
it additionally does *bundling* of things (*both* -generic *and* -extra)!!
(initial suggestion: perhaps "linux-image-deps-generic" or "linux-image-meta-generic")


If these packaging things were
properly hierarchy-arranged and thus more obvious, then
many infrastructure issues (like my suspend/resume fail) would likely be
much less bound to [usability-]occur.


Executive summary of this report:
always do
properly provide layers/levels of a hierarchy in full/symmetrically - do NOT
dirtily skip/shortcut interim steps!

HTH,

Andreas Mohr