On Mon, 30 Apr 2007 14:12:35 +0200, Johannes Berg <[EMAIL PROTECTED]> said:
> Hi, >> The setlocalversion script goes and changes the version of the >> kernel _after_ ./debian/ has been populated, which causes the >> ./debian/changelog and ./debian/control files to be out of synch >> with what the kernel thinks the version is -- and thus preventing >> the .deb from building. >> >> In any case, the setlocal version script always adds the -dirty- >> string to the version name -- since the ./scripts stuff also >> unconditionally nukes ./debian (whether or not it created it), >> which means that dpkg-buildpackage suddenly gets rid of /debian >> right at the beginning unless we intervene -- and intervening makes >> stuff dirty, and that changes the version number. >> >> So, given the way that ./scripts stuff messes up the build process, >> setlocalversion is not supported by make-kpkg. > All of this is true, but only if you invoke make-kpkg only once in > the same kernel tree or after the kernel tree has already been built > which typically happens in development trees. 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? > However, I still don't see this as a reason to kill the > setlocalversion script, make-kpkg could instead warn loudly when > CONFIG_LOCALVERSION_AUTO is set and tell the user to not do that > because it messes up the build process. 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? manoj -- Where the system is concerned, you're not allowed to ask "Why?". Manoj Srivastava <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]