Re: Forthcoming changes in kernel-package
On Fri, Feb 20, 2009 at 12:56:30PM -0600, Manoj Srivastava wrote:
> On Wed, Feb 18 2009, Theodore Tso wrote:
>
> > On Mon, Feb 09, 2009 at 12:14:49AM -0600, Manoj Srivastava wrote:
> >> Hi,
> >>
> >> This is a heads up for a major change in kernel-package, the
> >> tool to create user packaged kernel images and headers; which will
> >> make the make-kpkg script far less error prone, and far more
> >> deterministic.
> >>
> >> a. Every invocation of kernel-package will remove ./debian directory,
> >> and regenerate the changelog and control files. This will get rid
> >> of any remaining issues with the ./debian directory getting out of
> >> sync with the kernel sources; and will allow people to make small
> >> tweaks to the kernel sources and have make-kpkg reflect those
> >> changes.
> >
> > Is there going to be a way for people to replace the changelog with
> > one that contains useful information in that case? I've been doing
> > this by doing a make-kpkg configure and then editing the
> > debian/changelog file afterwards...>
>
> I have a plan for something like this, though currently there is
> no code. I was thinking of doing an "overlay" for ./debian, kind of
> like what ikiwiki and request-tracker do; so /usr/share/kernel-package
> contain the information that goes into ./debian; but if there is a user
> specified overlay, then files present in the overlay are used instead
> (files not in the overlay dir still come from the default location).
>
> I have not yet written the code, since there are several places
> in the build where we look for files in ./debian; and currently there
> is a fallback to /usr/share/kernel-package if ./debian does not exist;
> either I have to remove the fallback, or enhance the fallback mechanism
> (at potentially significant run-time cost).
>
> The cleaner solution would be for make-kpkg to always remove and
> re-create ./debian (with overlays), but make -f ./debian/rules never
> have to deal with anything outside (so to remove the fallback code that
> has sprouted all over the rules files). It might take a few iterations
> to do these changes, but I think it is worth it, for robstness' sake if
> nothing else.
>
> > BTW, I have a set of patches you might want to consider. I'll file
> > them in BTS if you're currently making make-kpkg.
>
> Please. I have been thinking about the request you made for
> debugging symbols being packaged, and now I do have some time to play
> with building kernels again, I would like to see that in Squeeze.
I know Troy Heber had submitted some patches for debug/kdump support -
those would be interesting as well :)
--
dann frazier
Reply to: