On Fri, 3 Aug 2007 13:25:38 -0800 "Jeff Spaleta" <jspaleta@xxxxxxxxx> wrote: > On 8/3/07, Kelly <lightsolphoenix@xxxxxxxxx> wrote: > > And this is why IMO non-kernel-packaged modules should be provided > > as plugins to DKMS. Then you don't have the "you have to repackage > > the modules after every kernel update" problem, because DKMS will > > do it automatically upon restart. And since this is for modules > > NOT considered "important" (as in, they wouldn't serve any real > > purpose in the main kernel), I don't see why having a dependency on > > the build tools is so bad. > > the fact that dkms itself doesn't depend on the build tools as > packaged already sort of already speaks to the issue of making dkms > payloads explicitly require gcc and friends. Forget about making them > depend on build tools its only complicating the argument you really > want to make. Just argue for things that depend on dkms in to fedora > sans any mention of build tools requirement. Anyone who wants to use > dkms can install the build tools needed to rebuild dkms payloads on > their own. > > The question that needs to be asked and answers is this: > Is there room in the baseline Fedora repository for dkms enabled > payloads or not? > > I'm all in favor of the upstream mantra, but I have to wonder, could > dkms payloads be part of a multi-step mechanism that Fedora could use > to try to help the upstreaming of out-of-tree modules? Can we have a > process where out-of-tree stuff shows up first as dkms enabled > payloads, that do not do anything out of the box, that expert users > can use and report bugs against and whatnot? And then from there > establish the upstreaming dialog that allows the module to be moved > into the fedora kernel package once its clear there is a dedicated > maintainer who is going to champion the upstreaming cause? > > If a timeout clock on out-of-tree kernel modules in our kernel package > is an icky idea for some people. Would a timeout on dkms payloads in > fedora be less-repugnant? > > I'd like to see a way that we could play around with experimental > stuff for a limited time, and then for the items that have > maintainership momentum towards upstream we make a longer term > commitment and include it in the kernel tree while the upstreaming > finalizes. I think limited time (aka deadman walking) dkms payloads > might make be that first experimental step, especially if they do not > work out of the box to draw a clear expectation boundary for > end-users. "This doesn't work out of the box, because these are > experimental and we want help getting them in shape for inclusion in > the mainline kernel." > > Or is dkms only being included in the repo for do-it-yourself end-user > convenience? Since we are shipping it it would be nice if we could > leverage it as part of an upstreaming process. > > thoughts? I think we are thinking of similar things, but to be sure I'll ask this question: By DKMS payloads, are you referring to DKMS-packaged source RPMs for the modules in question? So that a user would install dkms-foo-mod and then use dkms to build and install it? josh -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
