[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <sven.luther@wanadoo.fr> 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
backlog.

> >         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
removal time.

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
end-users-rebuilding-their-kernels.

> 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 :)

Friendly,

Sven Luther



Reply to: