** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux-restricted-modules (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: linux-restricted-modules (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Hirsute)
Importance: Undecided
Status: New
** Also affects: linux-restricted-modules (Ubuntu Hirsute)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Bionic)
Status: New => In Progress
** Changed in: linux (Ubuntu Focal)
Status: New => In Progress
** Changed in: linux (Ubuntu Hirsute)
Status: New => In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Andy Whitcroft (apw)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1928921
Title:
LRMv5: switch primary version handling to kernel-versions data set
Status in linux package in Ubuntu:
Triaged
Status in linux-restricted-modules package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
In Progress
Status in linux-restricted-modules source package in Bionic:
New
Status in linux source package in Focal:
In Progress
Status in linux-restricted-modules source package in Focal:
New
Status in linux source package in Hirsute:
In Progress
Status in linux-restricted-modules source package in Hirsute:
New
Bug description:
Switch fetching dkms-versions data for these packages to the kernel-
versions dataset.
Currently the primary dkms-versions data is committed directly to the
primary kernel packages. This allows this information to cascade
reliably to all derivatives and their associated LRM packages. But
once the primaries are closed it is increasingly hard to change this
data. This makes performing an LRM-only respin very difficult as it
differs in handling from a primary spin.
We move the primary version dataset out of the kernel packages into a
shared external "kernel-versions" dataset. Each package which needs
this data then obtains the information it needs directly, with it
committed locally to that package at update time.
This renders preparation of am initial (-1) spin and a later LRM-only
respin identicle. We simply update the shared dataset and perform a
no-change rebuild (./update-versions) on them and they will
automatically get the updated version information.
We will want to update update-dkms-versions in all primary main
packages, and introduce same into all LRM packages. As we already run
update-dkms-versions in the primary main packages, and are introducing
update-dkms-versions handling to update-versions in LRM this should
not change kernel crank proceedure. The cycle proceedure will need a
new step to update the shared kernel-versions dataset before cranking
commences.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
