[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: rc3 timeline



On Fri, Feb 25, 2005 at 08:41:52AM -0800, Steve Langasek wrote:
> On Fri, Feb 25, 2005 at 05:45:45PM +0900, Horms wrote:
> > > Holes that do not effect the installer enough to require an immediate
> > > update can be dealt with more slowly, we can let the fixed kernel debs
> > > get enough testing so we know they're solid before updating the
> > > installer, and we can even wait until the next major release of the
> > > installer to update it. The only additional concern might be GPL issues
> > > with the module binaries being out of sync.
> 
> > Ok, that sounds sensible. Could you elaborate on what you mean by GPL
> > issues. Are you talking about exported symbols and their GPL status?
> 
> This is in reference to the GPL requirements for distributing full source
> alongside any binaries, which is a bit tricky when we're building kernel
> udebs separately from the kernel debs and there's a possibility for them to
> get out-of-sync.
> 
> AIUI, the kernel-source and per-arch kernel source packages are carefully
> crafted such that a new revision of the kernel-source package doesn't
> prevent one from continuing using it to produce idempotent kernel-image
> packages based on the previous Debian revision.  There's no such safeguard
> preventing skew between kernel-image-$version-$arch and
> linux-kernel-di-$arch.

Thanks, understood. 

The way that kernel-source-2.4.27 packages are constructed, is such
that except when we purge things for DSFG reasons, all the patches
are inside kernel-patch-debian package, so you should be able
to roll back to any version. I suspect this helps this problem a lot.

> > >  1. kernel-image-2.4.27-sparc has not made it to testing yet. I think
> > >     kernel-latest-2.4-sparc is preventing it, since that package depends
> > >     on things like kernel-headers-2.4.27-1-sparc64
> 
> > This has an explicit dependancy on kernel-tree-2.4.27-8 (as it should),
> > so I guess uploading kernel-tree-2.4.27-9 would block it.
> 
> Not at all:
> 
> Package: kernel-tree-2.4.27
> Version: 2.4.27-8
> Provides: kernel-tree-2.4.27-1, kernel-tree-2.4.27-2, kernel-tree-2.4.27-3, kernel-tree-2.4.27-4, kernel-tree-2.4.27-5, kernel-tree-2.4.27-6, kernel-tree-2.4.27-7, kernel-tree-2.4.27-8, kernel-tree-2.4.27-8.mine, kernel-tree-2.4.27-8.r2289, kernel-tree-2.4.27-8.r2298
> 
> Perfectly by design...
> 
> > >  2. kernel-image-2.4.27-arm hasn't quite made it to testing yet either
> > >     (should today)
> > >  3. the powerpc 2.4.27 kernel still isn't updated either, and is
> > >     close to the point of not having an update included in rc3 at all.
> 
> > These packages do not have such a restrictive dependancy, so they would
> > be fine. Though I think that is a bug in there packaging.
> 
> Well, *that* may actually be a problem in terms of reproducibility of the
> build and GPL source requirements, so maybe someone should verify what arm
> and powerpc do with kernel-source patchlevels prior to release...

Yes, I agree.

-- 
Horms



Reply to: