Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed
On Thu, Jun 14, 2007 at 08:40:46AM +0200, Raphael Hertzog wrote:
> 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).
My two objections to this are scalability, and lack of comprehensiveness.
It's not scalable because it means the maintainers of the linux-latest-2.6
package have to centrally keep track of every package in the archive
providing a module metapackage; and it's not comprehensive because you say
at the end that you only want it to list packages that are autobuilt.
Why would it not be sufficient for the metapackages to each depend on the
corresponding linux-image package? That eliminates the need for a central
registry of such packages.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: