[kwlug-disc] ubuntu: why do newer kernel packages sometimes get held back on upgrade?

[Chris Irwin]

On Thu, 2010-07-01 at 16:25 -0400, Paul Nijjar wrote:
> I think it depends on the situation and the packages in question. 
> The apt-get manpage says about "upgrade": 
> 
> "Packages currently installed with new versions available are
> retrieved and upgraded; under no circumstances are currently installed
> packages removed, or packages not already installed retrieved and
> installed. New versions of currently installed packages that cannot be
> upgraded without changing the install status of another package will
> be left at their current version."
> 
> I could see several of the above situations applying in your case, but
> without knowing the packages in question it is hard to tell.

This is probably it. Ubuntu has two kinds of kernel packages. The first
are meta-packages (linux-image-generic) that depend on specific packages
(like linux-image-2.6.32-21-generic, which shipped with 10.04). The
latter actually provides a kernel.

The meta package will always depend on the latest kernel image. If there
is an update that breaks ABI, that comes in as a new package (current in
lucid-proposed is linux-image-2.6.32-23-generic). The meta-package is
updated to depend on the new kernel package.

Having the kernel in a separate package allows you to have both new and
old kernels installed, which the package manager wouldn't allow if it
was a normal single-package upgrade. Having the metapackage allows that
upgrade functionality you would otherwise lose by having new packages. 

As Paul noted, new packages are not installed in a safe-upgrade, you
must do a dist-upgrade to indicate that you're allowing the new packages
to be installed.

-- 
Chris Irwin <chris at chrisirwin.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20100701/150f4a7b/attachment.sig>