File: Multi-Arch

package info (click to toggle)
kernel-package 8.135
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 6,008 kB
  • ctags: 696
  • sloc: perl: 3,089; makefile: 2,344; sh: 538
file content (176 lines) | stat: -rw-r--r-- 6,813 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176

	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 (requiring an architecture 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 maintainer), 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
 arbitrary 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>

	For patches that are architecture independent, the special
 architecture all is used, as in /usr/src/kernel-patches/all/.

	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. Please note that,
 since run-parts will always run scripts in ascending order, the
 scripts in the unpatch/ directory should be numbered in reverse from
 the ones in the apply/ directory. Perhaps the number in the unpatch
 dir should be 10000 - number in the patch directory.

 The script <some name> should be something like 
============================================================
#! /bin/sh
set -e

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`
PATCHNAME=<patch name or number>

if test -f debian/APPLIED_$ARCHITECTURE_$PATCHNAME ; then
   exit 0 
fi

PATCHDIR=/usr/src/kernel-patches/$ARCHITECTURE

# Example on how to get current kernel version number etc
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/')

#Add test here for version numbers if we are finicky about versions

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

# Assume compressed patch
zcat $PATCHDIR/$PATCHNAME | patch `echo $PATCH_OPTIONS` 
# patch `echo $PATCH_OPTIONS` < $PATCHDIR/$PATCHNAME

echo "Removing empty files after patching" >&2
# make an exception for ./debian, or else the stamp files will go too.
find . -path ./debian -prune -o -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>

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`
if ! test -f debian/APPLIED_$ARCHITECTURE_$PATCHNAME ; then
   exit 0 
fi
PATCHDIR=/usr/src/kernel-patches/$ARCHITECTURE

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

# Is the patch compressed?
zcat $PATCHDIR/$PATCHNAME | patch -R `echo $PATCH_OPTIONS`
#patch -R `echo $PATCH_OPTIONS` < $PATCHDIR/$PATCHNAME

echo "Removing empty files after unpatching" >&2
# make an exception for ./debian, or else the stamp files will go too.
find . -path ./debian -prune -o -type f -size 0 -exec rm {} \; -print

rm -f debian/APPLIED_$ARCHITECTURE_$PATCHNAME
exit 0
============================================================

Manoj Srivastava <srivasta@debian.org>
~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*~*-,_.-*