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

[Seth Forshee]

On Mon, Jun 25, 2018 at 11:16:08AM +0200, Andreas Mohr wrote:
> Hi,
> 
> background: been trying to install more modern kernels on 16.04LTS (due to:
> 4.4.0 being semi-crashy on me, meta key interrupt handler race conditions!?).
> 
> I thus installed anything newer than that, e.g. 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, AFAICS, is the cause of
> a grave i915 DP suspend/resume issue on my Dell 9010 box)

We intentionally do not have linux-image-extra-* as a dependency of
linux-image-*. Not all environments need the drivers in
linux-image-extra, e.g. cloud environments where it's undesirable to
have those modules occupying disk space. The linux-generic meta package
is what general users are intended to have installed and will pull in
the packages required for general use, whereas the linux-virtual meta
package has a reduced set of dependencies.

<snip>

> Yeah - and any newer kernel - will fail!! (since
> such encapsulating/bundling meta packages are *NOT* properly provided for
> each such kernel version)
> The root cause is that
> package hierarchy is (doubly...) broken, AFAICS.
> 
> 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:

We have a package for letting you run a supported kernel from a newer
release in 16.04, linux-generic-hwe-16.04.

What we do not have (and imo do not want) is a meta package to let you
pick specific kernel versions. Installing that would lock you into that
specific version with no updates for security fixes, etc. The version
you gave above (4.8.0-58) is a great example -- that version is from a
year ago, and the 4.8 series is no longer supported in any Ubuntu
release.

You're welcome to install old, unsupported kernels if that's what you
want to do. Just don't expect us to make it simple ;-)

> 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 is
> a very simple plain pointer to be switched to
> the currently relevant versioned bundling package.
> 
> 
> 
> Also, naming "linux-image-generic" is
> a grave naming symmetry violation, since:
> the kernel package versions each already do have
> a package which is already called "generic" (*plus* the -extra package).

I can see how "generic" is used in the package names could be a little
confusing at first, but I don't think it's flawed. The linux-generic
meta package is what users are meant to install, and it will always pull
in the most recent generic kernel, module, and header packages.

> This despite the fact that
> the "only" distinction between linux-image-generic and linux-image-FOO-generic
> would sort of [usability-]expected to be the *VERSION*! (yet
> the merely non-versioned package name then astonishingly happens to
> provide *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 issues (like my suspend/resume fail) would be
> much less likely to [usability-]occur.

I fundamentally disagree that you need a meta package to let you install
a specific version of the -generic kernel along with the extras package
to solve your problem. We have two viable options:

 1) Report a bug, then we can see if we're able to resolve your
    speicific issue with the 4.4 kernel.

 2) Install the linux-image-generic-hwe-16.04 package so you can run the
    latest *supported* backport kernel from a newer Ubuntu release.

What we don't want is to let users easily pin themselves on an old,
unsupported kernel version with known security vulnerabilities.

Thanks,
Seth