Building testing kernels

Kamal Mostafa kamal at canonical.com
Fri Feb 4 19:03:26 UTC 2011


On Fri, 2011-02-04 at 19:41 +0100, Stefan Bader wrote:
> In the beginning I thought it to be a good idea to use ppas. But for test
> kernels it is rather bad as there only ever is one current version. For test
> kernels it turned out to be better to just build generic packages for amd64 and
> i386 and put those into a directory on people.canonical.com.
> 
> That way there can be individiual packages per bug.

On Fri, 2011-02-04 at 16:51 -0200, Herton Ronaldo Krzesinski wrote:
> Can't you create more than one ppa, to have a per bug set?

Yes you can!  You can make separate PPA's for each bug (or at an even
finer granularity if you like)  I do this all the time.

I very much prefer to use PPA's than to distribute my test kernels as
binary .debs...

First, the PPA system offers me (as a developer) an important measure of
protection that binary .deb's do not offer:  If a user installs a
binary .deb that I put up for download, and then the next day some awful
thing happens (their system eats itself, or they get attacked by a
hacker, or whatever) the user might be inclined to accuse me of having
planted some badness in that binary kernel.  By contrast, if I've
distributed it as a PPA, then the source that (provably) built the
kernel is right there for inspection -- I could easily prove that I had
not planted any badness in their kernel.

Second, if I were to get hit by a bus, having uploaded to a PPA would
protect my work from being lost.

PPA's are good.  The only down-side is the long build times.  (I always
build binary packages first on tangerine for my own hack-test-hack
cycle, but then when I'm ready to publish, I upload to a PPA).

 -Kamal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20110204/05899563/attachment.sig>


More information about the kernel-team mailing list