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 <firstname.lastname@example.org> said:
> On Tue, Jan 10, 2006 at 10:33:25AM -0600, Manoj Srivastava wrote:
>> reassign 346281 linux-2.6 thanks
>> 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
>> kernel-package has these requirements for the build and source
>> 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
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.
People are going to scream bloody murder about that. Seen on
Manoj Srivastava <email@example.com> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C