List of versioned kernels is not right for Ubuntu

Bug #1607845 reported by Jarno Suni on 2016-07-29
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
Julian Andres Klode

Bug Description

The following command outputs the list:
$ apt-config dump --no-empty --format '%v%n' 'APT::VersionedKernelPackages'

but the list does not 'contain linux-.*-tools' and 'linux-goldfish-headers', which are versioned kernel packages as well, if I have understood correctly.

On the other hand are these values appropriate for Ubuntu?

Same thing for Ubuntu 14.04.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: apt 1.2.12~ubuntu16.04.1
ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
Uname: Linux 4.4.0-31-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: XFCE
Date: Fri Jul 29 18:55:50 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-11-21 (250 days ago)
InstallationMedia: Xubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
SourcePackage: apt
UpgradeStatus: Upgraded to xenial on 2016-06-24 (35 days ago)

Jarno Suni (jarnos) wrote :
Julian Andres Klode (juliank) wrote :

There are no 'linux-goldfish-headers' packages. In fact, there is no package with goldfish in its name in yakkety.

Regarding 'linux-.*-tools', there is "linux-cloud-tools" which is missing.

Concerning the second part: They are mostly irrelevant, but they don't hurt. Better than keeping a packaging diff just to have a few lines less in an automatically generated config file... I think the modules part might be useful if you build stuff with module-assistant, but not sure.

So, unless I missed something, I'm going to fix the linux-cloud-tools (or linux-.*-tools, but that might be too broad?) part and thats it.

In any case, if that's an issue for you, you can easily work around it by adding your own stuff to "APT::VersionedKernelPackages".

Changed in apt (Ubuntu):
assignee: nobody → Julian Andres Klode (juliank)
importance: Undecided → Low
status: New → In Progress
Jarno Suni (jarnos) wrote :

This lists packages containing "goldfish":
According to it there is linux-goldfish-headers-3.4.0-4 for yakkety
Please note that I am talking about versioned kernel packages.
In Trusty,
apt-cache search --names-only '.*' | awk '/^linux-.+-[0-9]+\.[0-9]+.+/{print $1}' | grep linux-.*-tools
gives currently 473 matches of which 165 does not match "linux-cloud-tools" such as linux-goldfish-tools-3.4.0-3 and linux-lts-xenial-tools-4.4.0-31.

I have been creating a script that keeps linux kernel packages that have certain version and purge other linux kernel packages, so I was just wondering, if I have to care about the other operating systems. I am neither familiar with the kernels of other operation systems than linux nor their versioning. Do linux, kfreebsd and gnumach possibly share a version? It is hard to use the configuration variable to purge linux kernels exclusively for what it is worth.

David Kalnischkies (donkult) wrote :

btw: "apt-cache pkgnames" should have better/quicker result than searching.

Don't know what that goldfish is nor am I particular interested in cloud, but I guess they could be added if there is need/interest. Its not like there is any real cost attached to it and false positives are pretty unlikely with the kernel versions attached… in the case of goldfish it seems to be unneeded through as they have "normally" named images/headers packages, too, which depend on the strange ones, so the autoremover wouldn't kick in anyhow for those.

kfreebsd, gnumach (= hurd) do not share the same version, they do share the kernel postinst scripts which apt is using here through, so even through they use entirely different version schemes, its still a version we can work with. Excluding specific items depending on the architecture we built apt for would be possible, but not really worth the implementation effort I presume.

And yes, -modules/-kernel is for out-of-tree modules as created by module-assistant (from -source packages), but I think dkms can built packages, too, and its the naming scheme which tends to be used for packages for modules which happen to be distributable as binary builds… (not that there would be many).

Jarno Suni (jarnos) wrote :

If I purge other versioned kernel packages than the ones given, probably all kfreebsd and gnumach kernels will be purged.

Thus, I suppose I could use an (extended) regular expression to match versioned Linux kernel packages:

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers