Kernel Modules in Fedora -x

[Jesse Keating]

On Fri, 03 Aug 2007 21:49:46 +0200
Thorsten Leemhuis <fedora at leemhuis.info> wrote:

> Well, there is a need for those packages, if you like it or not, so we
> should fine ways to properly support them in rpm and yum. Wich isn#t
> the biggest problem. The big problem is to ship new modules when new
> kernels get shipped. We discussed this and gregdek and some others
> supported the idea to send out a "we are likely pushing kernel-update
> foo from updates-testing to updates proper in 24 hours" *if such a
> warning period is possible (e.g. not in the case of security
> updates). But that idea got lost.

We wouldn't have to worry about that if the modules were /in/ the
kernel package itself.  Then they'd get built at the same time and all
is love.  It's not really that bad to wait for your next kernel update
to get new modules in place.  Every other module has to wait as well.

> >  You could make the same argument
> > for any big package.  Why should oo.org-writer users have to
> > consume an oo.org update just to fix something in oo.org-impress?   
> 
> That a different problem -- deltarpm will solve that one afaics.
> 
> A similar (but not identical) problem would be pacakges depending on a
> exact version of firefox or pidgin (?). We have like other such strict
> dependencies and those share some of the problems with kernel-module
> packages (the "old kernels stay installed in parallel make the
> kernel-module case more complicated)".

Off in the weeds here, sorry I probably took you there.

> > [...]   
> >> But well, your statement IMHO shows nicely how Fedora sometimes
> >> acts. For heavens sake we at least got firefox.i386 due to the
> >> multilib mess (and firefox-32 thx to warren) -- otherwise we'd
> >> still would leave people out in the cold just do encourage
> >> 3rd-party plugin-writers to port their stuff to x86_64. Side not
> >> one the current "thinking about the Fedora brand" thread on
> >> FAB-list: maybe we should just say "Fedora only gives you what it
> >> thinks is good for you, even if it creates trouble and headaches
> >> for you".  
> > Don't confuse "how Fedora acts" with my opinions and wishes.  
> 
> I don't -- this is just another case. firefox.i386 in the x86-64 tree
> is another one.
> 
> >  I don't
> > have the authority to make new blanket policy and define new
> > rules.  
> 
> But you seem to be really interested in this topic and you are in the
> committee that is planing to kick kmod's, so it's IMHO your job to ask
> the Board for its opinion as it allowed kmod#s again not that long
> ago.

Sure, once the draft shows up I'll run it through the board if dwmw2
doesn't first.

> 
> > [...]  
> >>>> I'm just wondering in general about the current happenings --
> >>>> some months ago the Board issued a statement to allow kmods but
> >>>> now a new FESCo shoots it down again. Well, not my business as
> >>>> well.    
> >>> We're not saying no to non-upstream kernel modules, which is at
> >>> the heart of what the board wants (at least from my understanding
> >>> of the topic).  All we're doing is trying to redefine the delivery
> >>> mechanism so that it is easier for all parties involved.    
> >> And davej indicated that he does not want more out-of-kernel
> >> modules. That fact and the "at least from my understanding of the
> >> topic" IMHO makes it worth to ask the Board for its opinion.  
> > 
> > Having just had a conversation with Davej on irc, I can offer these
> > tidbits:
> > [...]
> > So it looks like Dave is absolutely willing to let out of tree
> > kernel modules in, so long as they have a hope of going upstream,
> > or a really really really good reason why we should continue
> > carrying it forward.  
> 
> Which leaves a lot of modules out. zaptel, spca5xx or gspca anyone?

We only looked at the ones currently in Fedora.  The rest would have to
be reviewed in their own time.  And as Davej puts, it's our
responsibility and onus to help these people with a grander long term
scheme which is getting these things upstream and becoming responsible
for them upstream instead of packaging them in N+ distributions.

> 
> > He even spoke of perhaps a timeout,  [...]  
> 
> We talked about that before and people said "to dangerous, as people
> will yell at us when module foo suddenly vanishes in Fedora (x+2)
> again.

The same danger exists when the kernel moves on and these modules no
longer compile without change.  That is the danger, and why we're not
interested unless there is interest in the module owner in getting them
upstream, as that is part of the responsibility, keeping them going.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070803/2f6cb8e1/attachment.sig>