Re: 2.6.12 upload
On Mon, 18 Jul 2005 15:19:05 +0200, Thiemo Seufer wrote:
> 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.
That's correct. This is why we'll end up w/ two different kernel
versions in unstable and testing. This is a feature, not a bug; we don't
want to carry around 20 different kernel versions because an architecture
can't get its act together.
> It is IMHO not realistic to expect the rest of the world to wait for
> some obscure subarchitecture.
Who said we're going to wait for some obscure subarchitecture? We're
going to keep working on kernels until we freeze for etch, at which point
the subarchitectures have a limit amount of time to catch up. I'd hope
they'd be able to keep up all along, but I'm not sure whether that'll be
the case. Regardless, if architectures can all catch up at some point, we
can get a kernel in testing that supports most everything; come freeze
time, it becomes real easy to stabilize. We'll still need to organize and
figure out what we'll be able to offer, and what sub/niche-archs we'll
have to drop. I suspect working from the same source package will force
us to communicate a bit more often, as well. :)
> - 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.
>
I don't think this will be an issue; we have enough development happening
at a given time that we can probably just do regularly scheduled releases,
w/ various architectures doing updates at the same time. We also have
enough security updates happening that we'll need to release pretty
regularly.. (blah).
Bah, the long list below makes my head hurt. I'll ignore a bunch of stuff
that I consider problems we can defer until some other time.. ;p
> 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.
Architecture-specific patches will be handled by subarch stuff. However,
given that nothing else is using the subarch stuff yet, and it's pretty
untested, I'll repeat what I said on IRC for the people playing along at
home; we'll skip mips/mipsel for now, and try to get it into the linux-2.6
package in the near future.
> - 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.
If subarches are to be used, then I assume each will have a different
subarch name. So, for example, linux-headers-mips-2.6.12-1 will be
depended upon by linux-headers-mips-2.6.12-1-sb1-swarm-bn, and
linux-headers-mipsel-2.6.12-1 will be depended upon by
linux-headers-mipsel-2.6.12-1-sb1-swarm-bn. Hopefully you'll pick
subarch names that differ. :)
The other possibility is to make the template generation stuff a little
smarter; if two flavours have the same name, instead of having
separate entries in debian/control, make it combine the two. That would
suck, but it's certainly doable. I'll defer that for now, though.
> - 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.
Ok, for these two, I guess the patch systems should be looked at; I have
not looked at it at all, however. This is some more subarch stuff that
I'm avoid for now.
> - 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.
I believe joshk had this complaint as well; apparently the unapply/orig
stuff got lost between kernel-source-2.6.11 and linux-2.6 packaging.
Joshk, care to readd this?
> - Only -p1 patches are accepted -> no CVS diff patches, originally
> psted patches can't be used easily.
This sounds like an easy fix that can be done later..
> - 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).
Oh god, the horror..
> - The shell-snippets-disguised-as-makerules generally fails to catch
> errors.
Reply to: