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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]