Re: 2.6.12 upload
Andres Salomon wrote:
> Alright folks, I think the packaging is ready to be beaten on by people.
> So, unless anyone has any concerns/problems/etc, I'm going to assume
> everything's a go for uploading 2.6.12.
> The current changes and state of the packaging:
> - source package is called linux-2.6
> - binary image packages have been renamed from kernel-image-* to
> linux-image-*. binary header packages have been renamed from
> kernel-headers-* to linux-headers-*. kfreebsd/hurd folks, if you have
> any comments/concerns/requirements, please be sure to let us know.
> - debian/control is generated from debian/templates/control.*.in, and
> naming/descriptions should be consistent across the various archs.
> - config files are generated from the pieces in debian/arch, with
> management of configs made a lot easier via tools in trunk/scripts
> (initconfig and split-config). I will probably tweak settings for
> the global config a bit more; expect some FTBFS for architectures
> until we figure out which options are safe for everyone, and which
> options are suitable only for certain archs.
> - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
> miscompiling things. however, if any architectures require gcc-4.0,
> either let me know, or update svn directly.
> - debian/README* and trunks/docs/ has information that kernel team
> members will find useful to understand the new packaging.
> - there are 3 patches that were in 2.6.11 that have been dropped due to
> lack of interest; sparc, alpha, and powerpc folks should determine
> their value, at some point.
FWIW, I gave up on the common kernel package for mips/mipsel for now,
and will build mips kernels via a linux-patch package which
build-depends on the source .deb. The reasons which prompted me to
do so are listed below, vaguely in order of importance.
Issues of the common kernel package:
- The 2.6 (instead of 2.6.12 etc.) versioning means previous versions
are thrown out of the archive, anything which isn't ready until then
will lose support.
It is IMHO not realistic to expect the rest of the world to wait for
some obscure subarchitecture.
- Coupling the smallest fix for a subarchitecture to a full upload of
the whole arch any package puts pressure on the autobuilder network
without much gain, and causes many users to download "new" kernels
identical to the old ones because of the version bump. -> E.g.
disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel.
- A generic header package is used, plus architecture-specific header
packages which add some bits like configuration defines and process
structure offsets. Architecture-specific header patches aren't taken
into account, but are needed for patches outside include/asm-$arch.
- Flavour names are assumed to be unique, this doesn't work well for
bi-endian machines (e.g. sb1-swarm-bn for mips/mipsel) and 32/64
- Architecture-specific patches are restricted to a single patch per
arch/subarch, with an $arch.* naming. This means to copy an identical
patch with different name to support mips/mipsel, it also means all
patches which may break some other architecture have to go into a
single file, which is ridiculous form a maintenance POV.
- Architecture-specific patches have no series mechanism, IOW they
aren't really updateable. Even if they had, it is not feasible to
keep multiple 2MB mips patches around for the whole duration of the
2.6 kernel series.
- The current patch system breaks easily down. If one of the patches
has a conflict, it is neither possible to unpatch the already applied
patches nor does a patch replay help (because the first already
applied patch conflicts now). So it's either rm -rf or to work around
the patch system.
- Only -p1 patches are accepted -> no CVS diff patches, originally
psted patches can't be used easily.
- If $EDITOR leaves a ~ backup file in the series directory, the patch
system doesn't check if the series name is valid and tries to apply
the copy as well.
- Same goes for the control file generation, some moved away directory
gets searched for control.in files as well, no check for valid arch
names or the resulting duplicate package definitions.
- The resulting control file suggests every available bootloader for
each image, with an [ $arch ] specifier. This is generally ugly and
doesn't help for e.g. mipsel subarches with per-subarch bootloaders
(colo, delo, sibyl).
- The shell-snippets-disguised-as-makerules generally fails to catch