On Tue, 2006-08-15 at 09:27 -0400, Jesse Keating wrote: > On Tuesday 15 August 2006 08:48, David Woodhouse wrote: > > I think this argument is invalid. We should ban _all_ module packages > > from Core and Extras anyway. > > I'm with David on this one. Packaging of modules is the path to insanity. It > requires all kinds of weird hacks to how they are built, how they are named, > how they are handled by rpm and depsolvers, they always lag, they always hold > users behind when critical kernel fixes come out, etc, etc, etc... Sorry. No. Not "always". Always is _always_ too strong a word, oh well, perhaps not? :-) ;-) :-) ALSA: I've been packaging ALSA kernel modules for years for the Planet CCRMA project (since 2001). Bumped my head against many walls in the process. Examined kernel packaging proposals that sounded fine till you used them and found they did _not_ work. I packaged kernel modules first out of necessity because the kernel did not include ALSA at all. Then also out of necessity to get newer versions of the ALSA kernel modules than the ones in the standard kernel tree - or modules for soundcards that have not made it to the kernel tree yet but are usable (and no, waiting for them to make it to the standard tree is not always an option). I'm not arguing for or against including kernel modules in extra or core or rhel or whatever - but there should be a solid guideline on how to package them that works. With proper support in resolvers, kernel infrastructure, etc[*]. If the current one has flaws (it does!) then let's fix them. The need exists, it is part of reality, denying reality will not make it dissappear (that's at least my experience over the years). I'm still using in Planet CCRMA a scheme similar to the one proposed. It works. -- Fernando [*] even support for the kernel itself has problems - if I have a kernel that is version-release older than the latest kernel I _can not_ install it using an unpatched yum. > I personally feel (as does David) that if the module isn't good enough for > upstream, then it would HAVE to live in the kernel package itself. If it's > not good enough for the kernel package itself, then it isn't good enough for > Fedora. (Same could be applied to RHEL, but that's a battle for a different > list). > > Arguing over which ugly ass hack to apply to be able to package kernel modules > is a bikeshed argument. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
