Re: Uploaded kernel-package 3.38 (source all) to master
Hi,
>>"Goswin" == Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de> writes:
Goswin> So does it work for m68k now or is it still i386 only? Will
Goswin> there be an 2.1.27 kernel source package? That shouldn't never
Goswin> go into stable, but for developers it would be nice.
Goswin> May the Source be with you. Mrvn
Well, we did not seem to have reached any consensus yet (there
was one person who said that all architectures should be included in,
period, and someone else mentioned that in practice that could be
months away).
Unfortunately, unless enough of the non-i386 people by in to
that, and unless the i386 kernel packages maintainer does it too,
merely changing kernel-package shall not achieve anything.
However, people have been mostly silent about this. Could we
have more comments, please, people?
manoj
--
"The experimenter who does not know what he is looking for will not
understand what he finds." Claude Bernard
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
======================================================================
It has been pointed out that the default kernel sources are
quite i386-centric. This is a proposal to address the requirement for
architecture specific kernel patches being required for (some? most?)
non-i386 architectures.
I understand that the patches are such that the kernel header
files may change (reuiring an architectire specific kernel-headers
package), and also kernel-doc, and of course kernel-image
packages. However, one would like to avoid uploading the huge base
kernel sources for every architecture, just for efficiency if nothing
else.
I would also like to enhance kernel-package to make it
possible for a user to download sources and build their own kernel,
regardless of architecture, as long as they have the requisite
patches for that architecture.
I guess this proposal is that there is one common, large
source package (maintained, as now, by Herbert Xu, the i386
maitainer), and every other architecture maintainer just release
kernel-patch packages.
make-kpkg from kernel-package will then be modified to be
aware of these patch packages, and incorporate the patch during a
kernel image build process.
A nice side effect of this proposal is that we can handle
arbitary patches as well, which could allow the authors of kernel
patches to say, for example, I have a nice new driver for device XXX,
to use in your kernel, get kernel-patch-yyy.deb, and rebuild your
kernel to use it.
With the new FLAVOUR variable getting incorporated into
kernel-package at the moment, one could then have multiple kernel
flavours by suitably modifying the patch scripts ;-)
----------------------------------------------------------------------
i386 Kernel maintainer:
kernel-source-<version>_<version>_all.deb # Common, large source package
kernel-headers-<version>_<version>_i386.deb ;
kernel-doc-<version>_<version>_i386.deb ;
kernel-image-<version>_<version>_i386.deb ;
kernel-patch-<version>_<version>_i386.deb ; i386 specific patches, if any
sparc maintainer
kernel-patch-<version>_<version>_sparc.deb ; sparc specific patches, if any
kernel-headers-<version>_<version>_sparc.deb ;
kernel-doc-<version>_<version>_sparc.deb ;
kernel-image-<version>_<version>_sparc.deb ;
m68k Kernel maintainer:
kernel-headers-<version>_<version>_m68k.deb ;
kernel-doc-<version>_<version>_m68k.deb ;
kernel-image-<version>_<version>_m68k.deb ;
kernel-patch-<version>_<version>_m68k.deb ; m68k specific patches, if any
; depends on Common,
; large source package
----------------------------------------------------------------------
The kernel-patch versions all depend on the generic source
kernel-source-<version>_<version>_all.deb, and all unpack into
/usr/src/kernel-patches/<architecture>/patch_<version>
The patch package explodes into(example for m68k)
/usr/src/kernel-patches/m68k/<patch name or number>
/usr/src/kernel-patches/m68k/apply/<some name>
The script <some name> should be something like
============================================================
#! /bin/sh
set -e
PATCHNAME=<patch name or number>
ARCHITECTURE=`dpkg --print-installation-architecture`
PATCHDIR=/usr/src/kernel-patches/$ARCHITECTURE
PATCH_OPTIONS= -l -p1 # -b/-z ? In the new patch, default is no backup
if ! test -d kernel -a -d Documentation ; then
echo "Not in kernel top level directory. Exiting" >&2
exit 1
fi
if test -f debian/APPLIED_$ARCHITECTURE_$PATCHNAME ; then
exit 0
fi
patch -R $PATCH_OPTIONS < $PATCHDIR/$PATCHNAME
echo "Removing empty files after patching" >&2
find . -type f -size 0 -exec rm {} \; -print
exit 0
============================================================
We can even have something like
/usr/src/kernel-patches/m68k/unpatch/<some name>
to uninstall the patches (undo the effects of apply/<some name>)
The script <some name> should be something like
============================================================
#! /bin/sh
set -e
PATCHNAME=<patch name or number>
ARCHITECTURE=`dpkg --print-installation-architecture`
PATCHDIR=/usr/src/kernel-patches/$ARCHITECTURE
PATCH_OPTIONS= -l -p1 # -b/-z ? In the new patch, default is no backup
if ! test -d kernel -a -d Documentation ; then
echo "Not in kernel top level directory. Exiting" >&2
exit 1
fi
if ! test -f debian/APPLIED_$ARCHITECTURE_$PATCHNAME ; then
exit 0
fi
patch -R $PATCH_OPTIONS < $PATCHDIR/$PATCHNAME
echo "Removing empty files after unpatching" >&2
find . -type f -size 0 -exec rm {} \; -print
exit 0
============================================================
This has previously been sent to:
----------------------------------------------------------------------
Eric Delaunay <delaunay@lix.polytechnique.fr> Sparc Debian
Herbert Xu <herbert@gondor.apana.org.au> Kernel Packages
James Troup <J.J.Troup@comp.brad.ac.uk> M68k
Manoj Srivastava <srivasta@datasync.com> kernel-package
Michael Alan Dorman <mdorman@calder.med.miami.edu> Alpha Debian
Michael Schlueter <schlue00@marvin.informatik.uni-dortmund.de> M68k
~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*
--
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: