First kernel upload for gutsy...priceless
zulcss at gmail.com
Fri May 4 19:02:42 BST 2007
On 5/4/07, Matt Zimmerman <mdz at ubuntu.com> wrote:
> On Thu, May 03, 2007 at 07:52:48AM -0700, Ben Collins wrote:
> > On Thu, 2007-05-03 at 12:33 +0100, Matt Zimmerman wrote:
> > > First, what's the rationale for splitting linux-ubuntu-modules into a
> > > separate source package? This requires an additional upload for every
> > > kernel ABI change, including some security updates, which is something we
> > > originally tried to minimize by bringing drivers in-tree. I think we're now
> > > up to four (kernel, ubuntu, restricted, meta).
> > The rationale is that it gives us clear separation of our stock kernel
> > code and our third party drivers (both in maintenance and in bug
> > tracking).
> How does it help for maintenance? Is it because you then use separate git
> > We had talked about this quite awhile back, with Kees and Martin, and
> > they both agreed that one more package would not be a problem at all.
> I worry that they are too polite to complain. ;-)
> > > I'm also concerned about the possiblity for users to end up without
> > > linux-ubuntu-modules, losing functionality. The ipw2200 firmware, for
> > > example, is in this package, and without it the driver fails in mysterious
> > > (to a desktop user) ways. The metapackages are convenient, but they have
> > > not been a panacea, and we already have occasional problems of this type
> > > with l-r-m.
> > The linux-image-generic package will depend on the matching kernel image
> > and ubuntu modules.
> > This means that it is impossible for someone to perform an upgrade from
> > feisty and get linux-image-2.6.22-1-generic, but not get
> > linux-ubuntu-modules-2.6.22-1-generic. There is nothing to cause the
> > kernel image to get updated without also bringing in the modules.
> > For them to get linux-image-2.6.22-1-generic without
> > linux-ubuntu-modules-2.6.22-1-generic, would mean they did not have
> > linux-image-generic installed, and manaually installed the kernel image.
> As I noted above, we have already seen problems like this in the field.
> Users do end up without the metapackages installed, and with unexpected
> combinations of packages. Users can and do manually install packages for
> one reason or another. I did it with 2.6.22-1-generic, and if I hadn't
> happened to know first-hand what you were up to, I would have been very
> confused indeed.
> 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.
> > > What happens if the patch fails to apply, or the patched source fails to
> > > build? How does it affect the build time for kernel uploads?
> > In order to get these patches in, I required that they be backed by our
> > community both in some measurable man power and in infrastucture. So
> > bugs on these packages, and patching issues that arise in them will be
> > handled by these teams (Ubuntu Studio and ubuntu-xen for example). If
> > issues can't be fixed, then the flavour will get disabled. Once we get
> > near release, we will evaluate the flavour for whether or not it will
> > remain for release.
> This is disconcerting to me. Once these patches are incorporated into a
> stable release, Canonical is committed to supporting them even if the teams
> behind them wane and disappear. If a security patch conflicts with one of
> them, this could seriously delay the testing and release of critical
> 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.
In the Xen case, since the xen kernel is going to be based off of
2.6.22. it would be difficult to keep up with the the ubuntu kernel
source with a separate source package in universe. Since I would have
to generate a new source each time figure out what has changed and
merge the xen bits into the new kernel. With the new build system in
place I just have to generate a patch that uses all of the shiny bits
that we have.
If something does break Ben can tell me that it broke and it has been
disabled. In this case I would get the latest tree from git, build it,
see where it broken update the xen patch and resubmit the patch to be
> > Since the new build setup will decrease the over all time for the
> > package build (last upload did not include concurrency support to take
> > advantage of the SMP buildd's, but next one will), I think the time we
> > save there makes up for the extra time to build the extra kernels.
> If we've gained extra time in the build, shouldn't we take advantage of it
> to make development less strenuous, with faster builds for kernel
> developers, rather than spending it on more kernel flavours in the main
> - mdz
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
More information about the kernel-team