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? -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
