Re: 2.6.12 upload

[Thiemo Seufer <ths@networkno.de>]

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.


Thiemo


Issues of the common kernel package:

General problems:
- 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.
 
Implementation problems:
- 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
  bit kernels.
- 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
  errors.