Re: Bug#346281: linux-image-2.6.15-1-686: debconf question about /lib/modules/2.6.15-1-686 even if no kernel is installed
On Tue, 10 Jan 2006 21:05:25 +0100, Sven Luther <sven.luther@wanadoo.fr> said:
> On Tue, Jan 10, 2006 at 10:33:25AM -0600, Manoj Srivastava wrote:
>> reassign 346281 linux-2.6 thanks
>>
>> Hi,
>>
>> If you have decided that putting the build link in headers is
>> correct, then you get to fix this. The kernel-package tool does it
>> dofferently, and while you are not required to follow what k-p
>> does, any non-standard and unsupported changes you make to the way
>> k-p works is your responsibility to fix.
> Whatever, i think the build directory should just work, and that was
> the agreement we had back then on this. I assumed this was indeed
> the case. Any idea what exactly is going wrong here.
Define "just work". And the agreement I recall was codified on
http://wiki.debian.org/KernelModulesPackaging
>> kernel-package has these requirements for the build and source
>> links:
>>
>> 1) A user building and installing kernel image packages on a single
>> machine must have a working build link
> As far as official kernels are concerned, we don't care about this
> case, and since the flavour will be different (a user building a
> flavour of the same name as the official kernels, and having the
> official kernels installed, has only himself to blame if things
> break :), whatever happens to self-compiled kernels is fully
> orthogonal to what is done for official kernels.
As the person who has to write and modify the special case
code, I beg to differ. I need some solid technical rationale and a
clear cost benefit analysis before any additional special case code
for official images would be added, and I am in the process of
eliminating the special case code we already have.
So, soon, there shall just be a vanilla k-p, the same for
anyone, and if there is any benefit for doing things one way, these
benefits should accrue to all users.
>> 2) A user who builds image and header packages and installs them on
>> other machines, must have a woking build link no matter which order
>> the image and header packages are installed
> identic here. Notice though that the header package always providing
> the symlink is the easiest and sanest way to have your criteria
> fullfilled.
Easy is for the person writing the code to decide. I have a
working solution, and I think changing it is harder, since it
involves new code.
>> 3) /lib/modules/$(uname -r)/build , if it exists, must point to a
>> valid directory, be it a dir provided by a headers package, or the
>> directory the kernel was built in.
> Ok, well, this is not so nice. For official kernels, there is no
> such thing as the directory the kernel was built in, so the build
> symlink *MUST* point to the dir provided by the header package.
I do not think you understand what I said.
If there is a build directory, the build links points to
that. If there is no build directory, but thre is a kernel headers
provided directory, then the build link points to that. Or else,
there is no build symlink.
>> 4) If you have installed a header package, but not the image
>> package, $(uname -r) indirection does not work, so you have to
>> manually set an env variable to point to the directory where the
>> headers live, and since you must set KSRC by hand, set it to
>> /usr/src/linux-headers-foo as you need. This does not add an
>> additional burdenm, it is not as if KSRC did not have to be set by
>> the user manually.
> Well, maybe, but it doesn't really change all that much all the
> same, and since both 2) and 3) favour havint the linux-headers
> provide the build symlink, i think it is obvious what should be done
> :)
2 does not favour it, and neither does 3, which you have
failed to understand. Look at the code to see what is happening.
manoj
--
People are going to scream bloody murder about that. Seen on
linux-kernel
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: