Re: new kernel-package breaks official linux-2.6 kernel builds, should not propagate to testing.
On Thu, 10 Nov 2005 02:03:15 +0000 (UTC), Horms <horms@verge.net.au> said:
> Manoj Srivastava <srivasta@golden-gryphon.com> wrote:
>>
>>> 1. the missing config caues manuals not to build
>>
>>
>> ,----[ Manual page make-kpkg(1) ] | DESCRIPTION | This manual page
>> explains the Debian make-kpkg utility, which is | used to create
>> the kernel related Debian packages. This utility | needs to be run
>> from a top level Linux kernel source directory, | which has been
>> previously configured (unless you are using the | configure
>> target). `----
>>
>> Previously been configured == has a .config file.
> This problem has been resolved by adding --config defconfig to the
> make-kpkg invocation that was failing. Its in SVN, and should appear
> in 2.6.14-3. However, as some targets, which don't need a .config,
> have worked in the past, I'm not sure that I see compliance with the
> above description as a good justification for making invocations
> that worked (flawlessly) in the past fail.
Let me address some of this. The old invocation worked, even
though that was not following the design, because the kernel package
internal mechanisms has become bloated, turgid, and almost
incomprehensibly complex over the decade or so of active
development.
The new modular rules file has sliced away layers of
obfuscation, and made sure that the dependencies for all targets were
correct -- and thus the requirement for the configure target being
done for all packages.
So, package building has been divided into stages --
configuration, building, installation into ./debian/foo; and .deb
build (the latter split into two parts: a wrapper that optionally can
call fakeroot and a second part where the package is actually built),
and clean. Each such phase has finer grained targets, and separate
for arch-dependent and arch-independent package building part. The
proper ordering of the phases has been abstracted away into a
separate file that does not need to be changed, once it is working.
With the new, streamlined, internal dependency mechanisms, it is
actually going to be a big kludge not to require the configure target
in the dependency path (since the dependency path has been separated
from actual make commands for targets).
I hope this helps.
manoj
--
Macho does not prove mucho. Zsa Zsa Gabor
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: