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

Re: Care to comment on plan for module building?



On Mon, Nov 07, 2005 at 03:08:30PM +0100, Sven Luther wrote:
> On Mon, Nov 07, 2005 at 02:29:52PM +0100, Jonas Smedegaard wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Hi Eduard (and cc kernel list),
> > 
> > I have put together a draft for future kernel module handling, based on
> > a discussion at the kernel list and spiced up with a few thoughts of my
> > own. It is available here: http://wiki.debian.org/KernelModulesPackaging
> > 
> > Could you please have a look and tell me what you think (or perhaps
> > simply edit that wiki page directly)?
> 
> Notice that you again sided with Manoj, depite him never providing any
> arguments in favour of not using the standard upstream mandated build symlink,
> and since both of you prefered resulting to insults instead of reasoned
> argumentations, i want to have no plan with any such plans as you have, so go
> ahead, and break everything for all i care.

I'm reluctantly entering this discussion, as it seems to be at an impass
to say the least. I must say that I really stuggle to understand why
everyone is so up-tight about this issue. I know there have been words
said in this thread and on IRC that might have been better not said, but
really, what is the issue? As far as I can see, the issue is that we
need to have a better framwork for out-of-tree module support.

There is the problem of the build/ link, which has historical behaviour
that dates back quite a number of years. Its current behaviour is not
entirely ideal from the point of view of users who only install
kernel-header packages. But it is quite useful for users who roll their
own kernel packages. And due to certain packaging limitations, it is
somewhat tedious to make it both have the historical behaviour that many
users might expect, and reach the expections of users with only
kernel-header packages installed. To be honest, its probably best to
stear clear of that link as much as possible when defining how modules
are packaged.

As for the wiki entry. I take it to be a work-in-progress document,
rather than doctrine. I personally don't find much at fault with what it
says. But I haven't been looking into the module build problem much.

I really think we should focus our energies on finding a module build
framework that works for packagers and uers. Rather firing harsh words
at each other.

-- 
Horms



Reply to: