Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 21, 2005 at 04:31:57AM +0100, Thiemo Seufer wrote:
> David Nusinow wrote:
> [snip]
> > > > If you have a single source package for 12 different architectures
> > > > that's great, because when you have a security fix you can take
> > > > care of that more easily. That's awesome.
> > >
> > > We have that already.
> >
> > Great to hear. Then what is this new plan that the kernel team
> > has? I'm definitely confused.
>
> For sarge, kernels are built in a two-stage process. First is to create
> a dsfg-free .deb from the upstream source which contains a source
> tarball, second is to build kernel images from another (arch-specific)
> .deb which build-depends on the source .deb. In the second stage,
> arch-specific patches can be added.
You forgot the third stage of the .udebs built.
> Post-sarge, it will be a one-stage process, which builds all kernel
> images from a single package.
>
> > > > But then you'll be trading off for the same problems that every
> > > > single other packge faces: namely that if a kernel on a single arch
> > > > has an RC bug then it affects the kernels on every arch. This strikes
> > > > me as being very problematic, and the only way I see around it is
> > > > to downgrade actual RC bugs, which isn't really a solution at all.
> > >
> > > Most kernel security bugs hit either generic code, or all architectures
> > > equally.
> >
> > Yeah, but I'm talking about non-security RC bugs. From what
> > little Sven has described I feel like the new kernel plan will
> > make it so these platform-specific bugs are problematic for all
> > architectures. Does the new integration from upstream take care
> > of this and if not, how does the kernel team plan to deal with
> > this issue?
>
> Those bugs are felt to be seldom enough, especially for already
> released kernels. For active development, there's a constant stream
> of fixes anyway, platform-specific things won't make much difference.
And a kernel-team with people from each architecture will make resolving of
them easier than a single maintainer in his corner who may or may not have the
knowledge for this actual fix, and may or not have time/whatever to fix it.
Friendly,
Sven Luther
Reply to: