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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Andreas Mohr-2
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)


$ dpkg -s linux-image-generic
Package: linux-image-generic
Status: install ok installed
Priority: optional
Section: kernel
Installed-Size: 14
Maintainer: Ubuntu Kernel Team <[hidden email]>
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!! (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:
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).
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.


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

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: "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

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team