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

Re: [wli@holomorphy.com: Re: NMU: kernel]



On Sat, May 22, 2004 at 03:41:30PM +0200, Christoph Hellwig wrote:
> > > and with that I mean the existing maintainers should cooperate.
> > 
> > Indeed.  But cooperation already exists.  So far, it meant that
> > Herbert took the upstream source, prepared a kernel-source package,
> > and put it up on people.d.o for the other maintainers to download and
> > prepare their arch-specific kernel-image packages.  Very efficient.  I
> > don't think we could come even close to this if we had one source
> > package for all kernel-image packages.
> 
> So your defintion of good cooperation is that e.g. in your
> kernel-patch-powerpc package two out of four patches aren't ppc-specific
> in any way?  And of the ppc specific ones both wouldn't harm any other
> arch because everything is under arch/ppc/

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.

> I really think everyone would be server much better with a single
> patchkit from that all kernels are built.

No, this looses us in fleibility, and we also get the risk of reaching
the upper barrier of the number of packages apt/dpkg can handle for a
single source package, as was shown in the debain-installer specific
kernel packages.

> For patches like your kernel-patch-powerpc that would be a no brainer
> because you already have properly splitted patches, but for some folks
> that would mean they'd have to stop simply diffing two kernel trees
> in favour of thinking what the actual changes are supposed to do.

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.

Friendly,

Sven Luther



Reply to: