Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed
On Sun, Nov 06, 2005 at 08:02:27PM +0100, Jonas Smedegaard wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On Sun, 6 Nov 2005 19:21:58 +0100
> Sven Luther <email@example.com> wrote:
> > Manoj's argument :
> > the build symlink is currently buggy, and should be either part
> > of the kernel-image package or created at kernel-image install time.
> I believe sven missed to comment on this early remark by Manoj:
Nope, i did not. I spoke at lenght with Manok about this on irc, check your
> > Can you explain to me why kernel-headers is not putting a
> > script in /etc/kernel/postinst.d and /etc/kernel/prerm.d to
> > optionally add and remove the build link?
> As I understand it, Manoj suggested to _optionally_ create/remove the
> symlinks in _kernel-headers_ packages.
Nope, the above scripts will be called during kernel *image* install and
It is a ugly solution to what we hve now, namely the symlink accompanying the
dir it links to, which is the less error prone.
> > Pro : Well, i will let manoj's reply here, didn't find any pro item
> > myself.
> > Con : doesn't allow building out of tree module without installing
> > linux-image for every flavour we want to build too, and as we
> > were trying to make this policy for module builds ...
> Wrong - if I understand correctly that Manoj was referring to -headers
> packages and not -image packages.
Well, see above :)
> > Martin's solution : instead of looking at
> > only /lib/modules/<version> to see if modules where installed,
> > actually do a find /lib/modules/<version> -name \*.ko, and search for
> > real modules.
> As I understand it Martin actually agreed with Manoj in his latest
> email (20051106153826.GA24360@deprecation.cyrius.com).
Yeah, but he was not aware that this breaks the plan for out-of-tree module
packages, and i believe will be more bristle than what we have now.
> I also believe this to be the most sane approach.
Ah, can you provide any kind of arguments for it ? I mean apart from the
purely esthetical onesi, which are subjective and of dubious relevance here ?
> > There are other stuff involved, in that over the years, k-p has been
> > more and more losing touch with the reality of the official kernel
> > packages,
> ...so he now suggests to move this out to a hook instead of hardcoded
> in k-p.
Yeah, well, but throwing out all the way official kernels have been forced to
override k-p upto now, and biasing his work toward
> I certainly feel this is sane!
Well, i doubt we are really interested in your feeling, arguments would be
more welcome, but after you have considered the full matter :)