linux-ports-meta -- Karmic/Lucid Ports Meta handling

Andy Whitcroft apw at
Wed Jan 20 10:42:44 UTC 2010

We have pulled the ports kernels back into the main repository and
indeed the main branch for karmic and later.  This has helped us
mightily to keep those kernels up to date with respect to security
updates and general fixing.  However although we are updating the kernel
itself we are not taking any role in handling the linux-ports-meta and
therefore which kernel is selected for the ports architecture.

Obviously as failures in the ports kernels are not blockers for the
other architectures we do need the meta updates for distro kernekl and
for ports kernels to be separate uploads to allow ports to lag should
they require.

Right now we have an issue particularly for -security updates where we
produce the entire stack and that has to be passed to the security team
for upload.  linux-ports-meta does not get included in this and
therefore was missed for the recent karmic security update.

I am wondering if linux-ports-meta should be pulled back into kernel-team
'responsibility' so we are responsible for keeping it in lockstep
for -security and -updates updates for karmic now and lucid and on as
they release.  That leave the issue of where to find and update the
meta package, it may make sense to pull linux-ports-meta back into the
linux-meta repository as a ports branch.

Anyhow, my aim here is to start some discussion on where we should go
with this.  My personal feeling is that pulling the ports source back
to the main repository has been very beneficial adding little work to
our team and significantly reducing the load on the ports owners while
keeping us in near lock step for the whole of karmic/lucid.  I suspect
that pulling meta back would have similar benefits, though we would want
some interlock on testing with the ports maintainers.



More information about the kernel-team mailing list