Re: Uploaded kernel-package 3.38 (source all) to master
Hi,
>>"Mrvn" == Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de> writes:
Mrvn> Manoj Srivastava wrote:
>> Umm, no, no actual kernel code ever goes into kernel-package;
>> people are encouraged instead to issue kernel-patch-m68k (or
>> whatever) packages conforming to the scheme outlined below.
Mrvn> Thats fine with me, but every now and then somebody complains
Mrvn> about the number of packages increasing. Maybe it would be a
Mrvn> good idea to have them in one package, the diffs should be so
Mrvn> few KB.
I do not have access to any other architecture, and I am loth
to include things into my package over which I have so little
control, and which I can't test. I think we'll have to live with
kernel-patch packages.
Mrvn> What I ment with the above was that the arch/m68k files from the
Mrvn> linux-m68k kernel should go into the main kernel source, cause
Mrvn> the m68k Source is the upstream Source for that. Whereas any
Mrvn> changes the linux-m68k made to other files not in arch/m68k
Mrvn> should go into the diff. The reason is that the arch/m68k files
Mrvn> should not break anything, and if they do it's not their fault,
Mrvn> whereas on other files the risk of breaking something is
Mrvn> high. This also benefit the merging back of the patches into the
Mrvn> mainstream kernel which should be the goal we are working
Mrvn> towards.
Hmm. I think I'd prefer to have the kernel sources distributed
by Linus be the default kernel source. This allows people to build
their kernel from downloaded kernel sources as and when they
desire. This also makes sense from a security perspective. I'd rather
have anything required for m68k not distributed by Linus to come in
kernel-patch-m68k package, as detailed in my proposal.
Mrvn> The asm link (and any other links) should be corected as
Mrvn> well. (Does make menuconfig/config/xconfig set asm right?)
This is already handled automatically by kernel-package.
Mrvn> It should also be possible to include a patch from a different
Mrvn> architekture with the help of the script so one can test if it
Mrvn> braeks anything. For this the script (sniped from below) is also
Mrvn> important, cause if it breaks or after testing people want their
Mrvn> original source back.
I think that the simplest thing to do would be to copy/symlink
the patch and script to the correct architecture and then try the
test. If things break, then just run the unpatch variant of the
script.
manoj
--
Anybody can win, unless there happens to be a second entry.
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . Trouble?
e-mail to templin@bucknell.edu .
Reply to: