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]
