Re: [wli@holomorphy.com: Re: NMU: kernel]
On Mon, May 24, 2004 at 10:27:00AM +0200, Christoph Hellwig wrote:
> On Mon, May 24, 2004 at 10:26:19AM +0200, Sven Luther wrote:
> > Which two of four ? at least the SFS patch is maybe not ppc specific,
> > but has never been tested on something else, (well, maybe m68k), and is
> > of use mostly on m68k and powerpc, since it is an amiga/morphos related
> > filesystem.
> > Furthermore, after discussion with upstream, he feels it is not ready to
> > go into the main kernels, and i would most assuredly not argue against
> > that.
>
> right, it's quite buggy in area and thus is misplaced in a kernel
> package, too.
>
> So once again it's too crappy for mainline but good enough for Debian?
> Does exactly sound like a way to assure high quality kernel packages.
Well, it is a module, if you don't like it, don't use it. It has no
impact on anyone not having such file systems, but for those who have,
it provides a service that is quite important for them, and would be
missing if it were not there. Again, i, as the pegasos upstream and the
powerpc kernel maintainer, take the responsability for this, so i
believe it is ok for inclusion in the debian powerpc kernel package. I
would not take the responsability to have it included in the m68k kernel
package though.
> > Well, even for ppc, the 2.6 kernel patch is a new development, let's
> > maybe more militate for having this model used on all arches instead of
> > the monolitic diff.
> >
> > That said, maybe it would be a good thing also to think of a mechanism
> > for all per arch packages to be rebuilt when the kernel-source package
> > is rebuilt, i believe this will be usefull. This is already the case in
> > the case of security fixes, but this is a special case.
>
> Given that everyone extremly dislikes the single source package scheme
> I think I'll give up the fight on this one. Following Jens' suggestion
> I'd at least keep a common CVS repository of patches though, even if
Please make it a subversion one at least. CVS is quite outdated, and has
very low fleibility in moving files around, which we will probably be
doing a lot. The ideal way of handling that would be to open a alioth
project for the kernel, and have space there for every kernel packager
(and third party module packager) to store their stuff in a common
(subversion) repository. Works pretty well for many other debian
projects. I still prefer the easier to use subversion over the more
obscure arch though, but i would abide with the decision of the other
users.
> there's differen kernel-image soure packages using it. That way we at
> least keep the patch mess under control (and avoid thing like asfs or
> asfs that are in no way arch specific sneak only into a single
> kernel-image) while giving the arch maintainers to rebuild at their
> will and not pushing dpkg limits yet.
Yes, i agree with that, altough i somewhat disagree with your way of
clasifying the patches. I think it is a good thing to have one or more
patches in a arch specific patch, be it for localized testing before a
wider usage, or because the patch, in despite of not being arch specific
is of restricted use outside that arch.
Friendly,
Sven Luther
Reply to: