[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Common kernel-image source package



On Tue, 10 May 2005 23:59:31 -0500, Manoj Srivastava wrote:

[...]
> 
>         Tentatively, my plans are like this:
>  a) Break up the /usr/share/kernel-package/rules file into smaller
>     blocks, and move them into separate, modules like:
>       /usr/share/kernel-package/include/BLAH.mk
> 
>  b) Take the current configuration section for each arch, and
>     move it out into (for example)
>        /usr/share/kernel-package/include/$ARCH/vars.mk
>          This top level file for the architecture, can then itself
>          include subarch specific files, like
>        /usr/share/kernel-package/include/$ARCH/$SUBARCH/vars.mk
> 
>  c) Decide on the make snippets to be handed over to the arch and
>     subarch (variables, double-colon targets, #defined canned
>     sequences, etc)
> 
>  d) Figure out a set of hooks for special case processing (it would be
>     really nice to support udebs)
> 

Heh, sounds a whole lot like cdbs1..


>  e) Make the maintainer scripts use debconf, and internationalize
>     them.
> 
>  f) Make it so that the ./debian directory shipped with the
>     kernel-image .dsc is self contained (currently, we tend to look
>     into /usr/share/kernel-package/ for some stuff). We should really
>     ship a ./debian directory that does not need make-kpkg to create a
>     kernel-image .deb package.
> 
> 

These two are sorely needed, imo.


>         I have semi working prototype code for some of this, but it is
>  mostly at proof of concept stage.
> 

I'd love to see the code you have so far.  My plan was/is to use cdbs2 for
the common kernel image stuff (code is available here:
http://svn.debian.org/wsvn/build-common/trunk/?rev=0&sc=0).  The main
goals of cdbs2 are to get rid of the awful gmake crap that's currently in
cdbs1, and make it easier for developers to do non-trivial things (as well
as understand the hooks and stuff).

Right now cdbs2
bootstraps, and I've got a test nano package that uses it
(http://mouth.voxel.net/~dilinger/rules).  Nano was chosen for complexity
reasons; multiple build directories, etc.  For things like udebs and
kernels, I had intended to have them as separate modules that the user
adds to *CDBS_MODULES.  So, 'CDBS_MODULES := simple-patchsys kernel', and
it handles calling out to kernel-package.




Reply to: