On Fri, 2007-05-04 at 14:10 -0500, [EMAIL PROTECTED] wrote: > I am not sure I understand these words. It seems to me that > the two cases you cite (invoking make-kpkg once, and invoking it > again after the kernel has been built) cover all possible cases. If > something is true in all possible cases, is it not true universally?
Hmm? I don't think I understand that :)
> What is the difference? make-kpkg clean restores the script,
> so it is not as if it is lost; and since the script messes up the
> make-kpkg build, why _not_ nuke it for the duration?
But I like having debian packages with the gX...X-dirty version :)
What I usually did was hack on the kernel, make, make M=... until it all
compiles, make again, then invoke make-kpkg kernel_image and install the
result. This allows me to remove everything from the kernel in a clean
way.
This used to work very well, I got debian packages with version
2.6.21-g65c44b40-dirty and was generally happy with that. Now
kernel-package kills the setlocalversion script leaving me with the
package version 2.6.21 which is fairly useless since I have many
versions of 2.6.21.
From what I can tell, nuking setlocalversion seems to be done for the
case where
(1) the kernel source is pristine and wasn't built before, so
setlocalversion wasn't invoked before
(2) the user has for some stupid reason set CONFIG_LOCALVERSION_AUTO
(3) that user is now trying to build a kernel with make-kpkg
(2) is why I'm questioning the point of nuking setlocalversion, any sane
debian kernel build surely won't be setting CONFIG_LOCALVERSION_AUTO
since it'll possibly even be included in the resulting kernel binary
as /proc/config[.gz] and simply be wrong because setlocalversion was
nuked
Right now I'm working around this by invoking make-kpkg, waiting until
it has nuked setlocalversion, aborting it, putting setlocalversion back
and invoking make-kpkg again :)
johannes
signature.asc
Description: This is a digitally signed message part
