Re: Debian kernel: various issues to discuss

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Jens Schmalzing <j.s@lmu.de> writes:

> Hi,
>
> Martin Michlmayr writes:
>
>> Some of the issues we'll have to think about are:
>
> Right.  Here's my 2 cents.
>
>>  - what kind of version control system are we going to use, how are
>>  uploads coordinated?
>
> I don't care much, not being particularly familiar with either arch or
> svn.  If you ask me, it's cvs, but that has become unfashionable of late.
>
>>  - [...]  I have to remind you to be gentle to each other
>
> On a Debian mailing list?  Come on...
>
>>  - We should try to have similar kernel config files on different
>>  architectures (except for arch specific stuff, obviously).  We
>>  should also discuss whether we should move towards using initrds on
>>  more platforms, and where they'd be useful.
>
> Sven and I implemented both for the 2.6 PowerPC kernel packages.  The
> .config files are assembled from stubs, the largest of which is used
> in all .config files.  The kernel are initrd kernels, but need to
> support more subarchs - currently they work on pmac and chrp.

Aren't all release archs building a kernel with initrd support that is
used in D-I? By the same reason all release archs should be using
initrd in sarge for at least on kernel-image or not?

>>  - We'll need to figure out how to handle different architectures.
>>  Can all of them be built from one tree, or is this not possible.
>>  We had discussions about moving to one tree in the past, but then
>>  people thought it was too hard and gave up.  I think we can only
>>  experiment to see if it's possible.
>
> I still believe that building all kernel-image packages from the same
> source will result in a monstrosity of a source package, slow down
> development, and unnecessarily reduce flexibility.  However, I'm all
> for checking the Debian specific stuff (patches, configs, and debian/)
> into one tree, so it becomes easier to review arch-specific patches
> side by side, streamline .config files, unify the build structure and
> so on.
>
> Regards, Jens.

Yes please.

One place where everything is available, can easily be audited,
automatically checked out and build and so on.

But seperate packages with seperate releases (unless there is a major
change like a security fix affecting all archs) so only needed
packages are rebuild and packages can be build in parallel (amiga, mac
and atari kernels in particular since they take so long).


I would like to have a tree structure:

vanilla source (cleaned up to be free)
          |
          |
   debian patches
     /    |    \
    /     |     \
 arch1   arch2  arch3 patches

And a script that makes a snapshot of the tree, packages up the
vanilla source package, builds the debian patches source package with
that and then builds each arch source package and notifies the
respective person for that arch.

The script could be smart enough to increase revisions on the packages
and notice when nothing has changed (e.g. no new vanilla source)

Say we have a security exploit in the kernel. The security team would
then add a patch to the "debian patches" and run the script. All
maintainers (or MLs) for each arch would get a mail telling them to
compile and upload the new, fixed package.

And so on.


There should also be a cron job that could check for new upstream
vanilla sources and do a nightly build of all source packages to see
if any changes introduce conflicts between the patches. That could be
done on any arch since it would only uncompress and patch the kernel
but wouldn't have to build complete images.

MfG
        Goswin