Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed
[Relayed to d-kernel by Cord Beermann <cord@debian.org>]
On Thu, Jun 14, 2007 at 08:40:46AM +0200, Raphael Hertzog wrote:
> Package: linux-latest-2.6
> Version: 2.6.21-4
> Severity: wishlist
>
> It would be great if we could have a mechanism to avoid installing a newer
> kernel if the packaged modules that the user has installed are not yet
> available. A simple example: I have 2.6.18-5 with the corresponding
> kqemu-modules 2.6.18-5.
>
> Yesterday I upgraded to sid and linux-image-2.6-686 pulled the new 2.6.21
> kernel. However there's no kqemu-modules for 2.6.21 and thus I lost
> support during the upgrade even though I have kqemu-modules-2.6-686
> installed.
>
> My suggestion to solve this is to use the new "Breaks" field as soon as
> it's introduced in dpkg (it's planned in the next dpkg upload,
> apt does already support it).
>
> linux-image-2.6-686 in version 2.6.21+7 would be marked as breaking
> the old versions of packages like kqemu-modules-2.6-686.
>
> Package: linux-image-2.6-686
> Breaks: kqemu-modules-2.6-686 (<< 2.6.21+7), unionfs-modules-2.6-686 (<<
> 2.6.21+7), ...
>
> That way the package manager has a clear hint on when it can safely
> proceed with the upgrade.
>
> However when you do this, you must also decide to regularly update the
> linux-modules-{contrib,extra} packages. Of course, you should only list in
> the Breaks field the packages that are autobuilt. Those that are only created
> by the user with modules-assistant shouldn't be listed other the upgrade
> will never happen (unless the user is clever enough to do it by himself).
This is why i proposed instead to handle the kernel packages otherwise,
outside the normal kernel infrastructure.
We would have a kernel part of the archive, which would be independent
from the normal stable/testing/unstable/experimental setup.
In it, we would have a per kernel-abi version sub hierarchy, which would
contain all modules and other kernel related stuff (even .udebs), so
there would *NEVER* be this kind of breakage, nor a breakage of the
netboot d-i images, since we would always have a given abi available.
Then, we could simply extract from this pools the needed packages to go
in a given distribution, either into unstable (once all dependents are
built, and we are happy with the general non-buggyness), or migrated to
testing, or stable.
This would also make building stable point-release with upgraded kernels
much easier.
If in addition, we separate the d-i image between the kernel-related
part and the non-kernel related part, we can easily, without big
recompilation, produce new images with any of these kernels.
I know that trying to push these ideas is what landed me in the current
mess, but it is what makes the most sense, it is an elegant and clean
solution to all these and related problems, so i ask you to consider it
by itself, instead of rejecting it because it comes from me.
Friendly,
Sven Luther
Reply to: