First kernel upload for gutsy...priceless

[Matt Zimmerman]

On Sun, May 06, 2007 at 12:19:30AM -0700, Ben Collins wrote:
> On Fri, 2007-05-04 at 15:01 +0100, Matt Zimmerman wrote:
> > A user who has linux-image-2.6.20-15-generic won't realize that
> > linux-image-2.6.22-1-generic is something quite different from a later
> > version of the same tree.  We should always be very careful when changing
> > the semantics of a package without changing its name, because it will clash
> > with user expectations.  In this case, the price of unmet expectations can
> > be, at worst, a system which doesn't boot.
> > 
> > The only way to reliably avoid inconsistency is with strict dependency
> > relationships.  If foo 1.0 is equivalent to foo 1.1 + bar 1.1, it's
> > appropriate for foo 1.1 to depend on bar.  Consider dpkg and dselect for an
> > example of a similar situation, and the care with which it was handled.
> 
> We get this from release to release even without creating the problems
> ourselves :) I was looking at adding a Recommends for
> linux-ubuntu-modules to the linux-image packages to help alleviate this.

How do you mean?  I don't see how this sort of problem can occur without us
reorganizing the packages.

I'm pretty sure we still have a situation where many users are using the
-386 kernel, when they should be using the -generic kernel, because we
didn't properly handle that transition when renaming -686 to -generic.

> > Wouldn't it be wiser to keep these separate?  If these secondary flavours
> > were provided by another source package in universe, this would avoid
> > blocking core development.
> 
> If we kept them separate, it increases the amount of effort to do
> security uploads, since _every_ upload of linux-source (with or without
> ABI bump) would require us to rebuild linux-xen, linux-openvz, linux-rt,
> and that's much more overhead than maintaining the diff in our tree. Not
> to mention, if these packages move to main, we are committing ourselves
> just the same. Keeping them in the main tree actually helps to maintain
> them.

I don't agree; there's no reason we would be forced to rebuild any of them
(that's the point).  They would be self-contained, with their own kernel
source, which could be merged whenever the maintainer felt the need, just by
pulling the right git tree(s).

I explicitly don't think such packages should be in main.

-- 
 - mdz