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, Jan 10, 2006 at 04:00:00PM -0600, Manoj Srivastava wrote:
> 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
Jonas and you wrote that one unilaterally despite my protests, i don't
recognize that document. And since jonas seems to be kind-of MIA since a
couple of weeks, this leaves only you.
The agreement we had was that the build symlink would always point to a valid
directory, which is provided by the linux-headers package for official
kernels. I don't care what you do or not for non-official kernels, but on
behalf of the kernel team i ask you to not unnecessary break things.
> >> 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, just always have the build symlink with the headers. The special case of
having the build symlink point to the non-packaged sources, well, it could be
handled with a diversion or whatever, or just be there. or in some other way.
> 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.
Sure, you are just too stuborn to actually see our needs. You still consider
the official kernel packages as second class citizens.
> >> 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.
You have a broken solution as far as the official kernels are concerned. I
don't care what you do, and we provided code for you to ignore the build
symlink when doing that nasty check everyone ignores anyway, but you wouldn't
take it.
> >> 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.
Sure. you take lot of hoops and special cases for a situation which will
*NEVER* arise with official kernels. Just have the header package carry the
symlink for official kernels, and be done with it.
> 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.
There is no build directory for official kernels, and the only valid point for
the build symlink to point to is the dir provided by the header package, so
there is no build directory, the kernel headers are installed, then per your
own words, the build symlink should point to this, independently of if the
kernel-image is installed or not. This is what we actually agreed upon, and if
k-p did this, nobody would ever be complaining.
> >> 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.
Sure it does. The most sure way of having the build symlink always point to
the right place, is to accompany that symlink with the dir it points to, that
is, put it in the header packages for official kernels.
Anyway, i don't think this will bring anything, and last time we discussed
this, you ended up with abuse and insults against me, and when all thought you
had solved the issue, and everyone was happy, you suddenly come again with
this brokeness.
Friendly,
Sven Luther
Reply to: