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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
