batchbuild several kernels (was: Re: Bug#19546: ...)
Hi!
I requested a batchbuild feature for kernel-package because:
>> - I can't / don't want to waste space for kernel-sources on each machine.
>> - It simplifies handling of gcc-less machines (eg. router).
>> - slow machines take ages to compile their kernel - so I prefer to compile
>> their kernel on a fast machine and simply install the resulting
>> kernel-image*.deb
>> - roll-out of a new kernel / bugfix like teardrop is much more comfortable
>> because there's only one source tree to maintain. Then I only need to
>> check the old configs, start batchbuild, install new kernel
recently I added (why I can't / don't want to run default kernel):
- I run some machines with *MUCH* too less memory
- some machines won't boot reliable with the default kernel
- I have some additional feature and bugfix patches applied to my
kernel-source.
- some machines need CONFIG_FIREWALL and so on
Manoj Srivastava wrote:
> I'll try to answer this point by point. On reflection, I think
> it would be best to build on top of the current kernel-package,
> rather than modifying the behaviour. I do not think it is necessary
> to change the current set up (and this is widely enough used that
> there shall be howls of protest if make-kpkg broke ;-)
yes, indeed, that sounds better. But somehow my brain got stuck with multi
binary debs and I concluded It would be easier to modify make-kpkg ...
Ahh - I remember: It was the "Source:" Field in the control file. But reading
Manoj reply I started thinking that this isn't necessarily needed for local
packages.
> I suggest a script that would:
> a) test for and ask the user to modify the top level Make file in
> kernel sources to have the FLAVOURS variable set (read Flavours
> in /usr/doc/kernel-package) --- umm, for newer kernel-packages
yes and I think that question should be overrideable by an entry in a
config-file and/or a commandline switch.
It'd be nice, if Herbert Xu could include the FLAVOUR-patch in kernel-source.
> b) looks at (say) /usr/local/etc/kernel/configs/*; and copies each
> file to /usr/local/src/kerns-source-2.1.84/.config (modify for
> local pathmnames); runs make-kpkg clean; make-kpkg kernel_image)
> Alternative locations (it this were to be included in a Debian
> package are: /etc/kernel/configs/ and /var/spool/kernel/images/)
Hmm, right now I like the debs being created in "..". dpkg-genchanges assumes
the same. But it should be implemented configurable.
But I'd like to have the configs in /var/lib/kernel/configs or so. Configs
for different machines than the compiling machine needn't waste spcae on the
root-fs.
when FLAVOURs are allowed by user/config/cmdline
kernel-images would get the FLAVOUR from the filename (unless filename is an
invalid FLAVOUR)
kernel-source's FLAVOUR could be empty, "local" or `hostname -d`.
hmm - seems like another candidate for the cfg. Another possibility is, to
put an empty file named _source_<FLAVOUR> in the cfg-dir
So those Packages would coexist with each other (and the original Packages)
within dselect.
BTW: How is FLAVOUR limited?
IIRC dpkg allows alphanumerics, '+-.'
Since I can't guarantee an epoch ':' is prohibited,
make-kpkg always adds a debian-revision, so '-' is ok for dpkg.
which limitations origin in the kernel, klogd, syslogd, kerneld, modutils,
uname, .... ?
I guess FLAVOUR shouldn't be too long - but what's "too long"?
> c) moves kernel image to /usr/local/etc/kernel/images/blah
> d) goes for the next one.
> e) make-kpkg binary-indep kernel_headers to generate the other debs
> e) Looks at the changelog (possibly in
> /usr/local/etc/kernel/changelog), and craft a changes file, and
> asks for the signaturte (also sign the dsc file)
hmm - that part needs a little research. I could try to make a .changes for
kernel-source and then fix the rest.
But since such Packages would never be uploaded - do we need .changes?
> I leave it up to you to decide whether you want to create a
> separate package for this, or if you are willing to wait until
> after the release of hamm to incorporate it into kernel-package.
I'd realy enjoy putting something together.
Manoj, is it worth becoming a new Maintainer (and updating to hamm), or are
you faster adding such a script to kernel-package?
Anyway it isn't urgent to get such a script.
> Rainer> make-kpkg checks for those files and adds an
> Rainer> kernel-image entry for each machine to the control-file:
> Rainer> Package: kernel-image-<hostname>-2.0.33-<flavour> when
> Rainer> make-kpkg is called with a kernel-image-<hostname> target it
> Rainer> copies debian/config.hostname.cfg-release to .config, adds
> Rainer> <cfg-release> to the FLAVOUR, runs
> Rainer> /usr/lib/kernel-package/rules kernel-image
>
> Too complex. I do not think automatically adding to the
> control file can be done safely, and I fail to see why it
It'd be possible by splitting the control template in two parts:
one for the non-image packages and one for images. Then I can add as many
images as I want. But thats obsolete anyway.
> You only need to craft the changes file to add new
> images. For a local set up this is not needed, so I think you are
> indeed talking about a general capability here.
or to mention new patches.
and indeed: I often tend to think too general ;-)
> Rainer> Maybe we should move a possible discussion to one of the
> Rainer> lists? Was it correct to submit this as bug?
>
> Well, we can move to debian-devel to discuss this. I think
> my proposal above would do all you are thinking of doing, without
> radically changing kernel-package (which is designed for a one
> machine level). Please flesh out the details; and yes, please
> present the design on debian-devel, so that people may poke holes in
> it (One needs a thich skin nowadays ;-). Or if you wish, I would
> probably get around to it in a few weeks (after release of hamm).
> How does that sound?
...
> Oh, and, BTW, did you know that there is a copy of the config
> file now in the image.deb, and that config files are now stored
> on /boot?
I read it in the changelog, but I didn't realize how cool that is! :-)
Regards
Rainer
---
KeyID=58341901 fingerprint=A5 57 04 B3 69 88 A1 FB 78 1D B5 64 E0 BF 72 EB
--
E-mail the word "unsubscribe" to debian-devel-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@lists.debian.org
Reply to: