(fwd) Re: Uploaded kernel-package 3.38 (source all) to master
This seemed germane to the discussion we've been having about architecture-
specific kernel patches... It's from debian-devel...
Bdale
-- forwarded message --
Path: gag.com!mail-gateway
From: srivasta@datasync.com (Manoj Srivastava)
Newsgroups: list.debian.devel
Subject: Re: Uploaded kernel-package 3.38 (source all) to master
Date: 17 Sep 1997 23:37:57 -0600
Organization: Manoj Srivastava's Home
Lines: 232
Sender: news@gag.com
Message-ID: <87202nfaqu.fsf@tiamat.datasync.com>
References: <199708291717.MAA22177@tiamat.datasync.com>
NNTP-Posting-Host: winfree.gag.com
X-Server-Date: 18 Sep 1997 05:37:57 GMT
Xref: gag.com list.debian.devel:26875
Hi,
Mrvn is right. The last ime I brought this up, there was one
person saying that all patches should e rolled into the main
distribution, and another said that though very laudable, it might
take time to achieve that utopia. I side with the latter view, in the
near future, I think, there always will be patches.
So, since only two people responded on the two times I have
brought this issue before this forum, I am assumng that the
silent majority is wildly enthusiastic and concurs with me ;-), or at
least, there are no objections.
I have therefore modified kernel-package to be aware of
kernel-patch-<NAME> packages. I am including the proposal (again!)
below.
>>"Mrvn" == Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de> writes:
Mrvn> Nobody joined the discussion about the kernel package, so they
Mrvn> all seem to perfectly have the same opinion about it (if not,
Mrvn> get your hands on the keyboard and write).
Mrvn> Maybe the idea mentioned earlier in this thread should be done
Mrvn> and a new package be uploaded soon.
Mrvn> The idea was to have the kernel package work for all systems
Mrvn> debian runs on bye: (Correct me if I'm wrong)
Mrvn> - Adding all arch specific files and patches of each arch to the package
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> - Makeing a diff for all changes to common files or files from different
Mrvn> archs.
Making separate patches for each architecture? I didn't quite
understand the sentence above.
Mrvn> - Make a Package from the source and the diffs
???
Mrvn> - Have the diff for the arch aplied to the source during installation
Mrvn> ( - have a command to remove a diff or add a diff to the source [make
Mrvn> m68kdiff or make m68kundiff )
I went with the patch suppliers putting a shell script in
a well known directory. That way, people can put in tests (grab the
kernel major and minor version from the Makefile, and abort if
necesary, or ensure compatibility with patches being applied at the
same time). Please look at the example patch scripts in the proposal;
I think you'll like them.
manoj
--
"If you want to eat hippopatomus, you've got to pay the freight."
attributed to an IBM guy, about why IBM software uses so much memory
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
======================================================================
kernel-package has now been enhanced 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.
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 guess this proposal is that there is one common, large
source package (maintained, as now, by the i386 maitainer), and every
other architecture maintainer just release kernel-patch packages.
make-kpkg from kernel-package has been modified to be aware of
these patch packages, and incorporate the patch during a kernel image
build process. This option is turned off by default, and is only
invoked when a ENV variable PATCH_THE_KERNEL is defined (config file
support also present).
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>
/usr/src/kernel-patches/m68k/unpatch/<some name>
The advantage of using scripts is that patch writers can add
their own tests, based possibly on the kernel version or patchlevel,
or looking at other patches already installed, etc. /bin/run-parts
then can be run over the appropriate directory. The script <some
name> should be something like
============================================================
#! /bin/sh
set -e
PATCHNAME=<patch name or number>
PATCHDIR=/usr/src/kernel-patches/$ARCHITECTURE
if ! test -d kernel -a -d Documentation ; then
echo "Not in kernel top level directory. Exiting" >&2
exit 1
fi
ARCHITECTURE=`dpkg --print-installation-architecture`
VERSION=$(grep ^VERSION Makefile 2>/dev/null | \
sed -e 's/[^0-9]*\([0-9]*\)/\1/')
PATCHLEVEL=$( grep ^PATCHLEVEL Makefile 2>/dev/null | \
sed -e 's/[^0-9]*\([0-9]*\)/\1/')
SUBLEVEL=$(grep ^SUBLEVEL Makefile 2>/dev/null | \
sed -e 's/[^0-9]*\([0-9]*\)/\1/')
PATCH_VERSION=$(patch -v | head -1 | sed -e 's/[^0-9\.]//g')
if dpkg --compare-versions $(PATCH_VERSION) >= 2.2
then
PATCH_OPTIONS= -l -s -z -p1
else
PATCH_OPTIONS= -l -s -b -p1
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
touch debian/APPLIED_$ARCHITECTURE_$PATCHNAME
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>
PATCHDIR=/usr/src/kernel-patches/$ARCHITECTURE
if ! test -d kernel -a -d Documentation ; then
echo "Not in kernel top level directory. Exiting" >&2
exit 1
fi
ARCHITECTURE=`dpkg --print-installation-architecture`
VERSION=$(grep ^VERSION Makefile 2>/dev/null | \
sed -e 's/[^0-9]*\([0-9]*\)/\1/')
PATCHLEVEL=$( grep ^PATCHLEVEL Makefile 2>/dev/null | \
sed -e 's/[^0-9]*\([0-9]*\)/\1/')
SUBLEVEL=$(grep ^SUBLEVEL Makefile 2>/dev/null | \
sed -e 's/[^0-9]*\([0-9]*\)/\1/')
PATCH_VERSION=$(patch -v | head -1 | sed -e 's/[^0-9\.]//g')
if dpkg --compare-versions $(PATCH_VERSION) >= 2.2
then
PATCH_OPTIONS= -l -s -z -p1
else
PATCH_OPTIONS= -l -s -b -p1
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
rm -f debian/APPLIED_$ARCHITECTURE_$PATCHNAME
exit 0
============================================================
Manoj Srivastava <srivasta@debian.org>
~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*
--
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 .
-- end of forwarded message --
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org . Trouble?
e-mail to templin@bucknell.edu .
Reply to: