Re: Proper way for vendors to build deb packages of kernels.
On Sun, 2014-12-07 at 11:15 +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Sat, Dec 06, 2014 at 12:24:55AM +0000, peter green wrote:
> > Currently the raspberry pi foundation build their kernel and
> > firmware into the same package in a way that does not work with dkms
> > or generally integrate with Debian stuff. I've recently been talking
> > to shiftplusone (who works for them) about the possibility of
> > improving this.
> >
> > Currently i'm aware of three ways of building deb packaged kernels.
> >
> > 1: modify the Debian "linux" source package
> > 2: use make deb-pkg
> > 3: use make-kpkg
> >
> > Option 1 can be made to work and probablly gives the closest
> > experiance to kernels actually from Debian but it's a PITA,
> > especially if there are a large number of changes from the source
> > tree Debian uses. We do produce kernel package from a mashup of the
> > Debian "linux" source package and the raspberry pi foundation's git
> > tree but they are a pain to update and so tend to be updated far
> > less frequently than the raspberry pi foundation's kernels.
> Once you worked a bit with the kernel source package it's quite nice.
> OK, it's a big and complicated package because it generates a big amount
> of architecture specific packages, but for the complexity it handles
> it's really nice (IMHO).
>
> I'd go for this option,
FWIW so would I. I'd expect 90% of the work it be "just" replacing
debian/patches and debian/config with Raspbian specific stuff (where
debian/patches might be nearly empty or one big megapatch resynching
with the Pi-foundations releases, depending on how that upstream works).
> and I'm sure if you drop by here or in
> #debian-kernel with problems you'll find help. Parallel to that I'd
> recommend what Paul Wise said: Try to get your code into mainline.
> For learing about the kernel package I consider debian/README.source
> more helpful than the wiki, so you might want to take a look into that.
Ack to all that too.
> > Option 2 doesn't seem able to produce source packages, so it's ok
> > for packages built for yourself but no so good for stuff you are
> > going to distribute (much easier to track license compliance if you
> > have a corresponding source package for every deb).
> Right, make deb-pkg is great for local testing ony.
Mostly agreed.
The recent deb-pkg stuff these days (for a while now) does include
headers packages and integration with the bootloader hooks etc so it's
actually pretty good for local deployment too. The main lack WRT
distributing the result is the lack of a .dsc.
I'm not sure what it would take to add source package support to the
upstream kernel, but I bet there would be a bunch of people who would
find it useful.
> > Option 3 also doesn't seem able to produce source packages and
> > furthermore seems to be rather undermaintained (the readme for
> > example still references libc5)
> Yeah, 3 is generally not recommended any more.
Agreed.
Ian.
Reply to: