On 03.08.2007 21:15, Jesse Keating wrote: > On Fri, 03 Aug 2007 20:24:00 +0200 > Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote: > >> There are lot's of cases and situations in the world where >> kernel-module packages are needed -- updated or new open-source >> drivers for testing are a valid area IMHO. I think we should not >> ignore those and other cases completely. > And every single one of those cases has lead to very difficult to > manage user situations or lots of really really ugly hacks to make rpm > and yum handle this bad situation. 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. > 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)". > [...] >> 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. > [...] >>>> 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? > 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. CU knurd -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
