On Mon, May 24, 2004 at 03:53:51PM +0200, Sven Luther wrote: > For out of tree module writers, yes, but not as debian packages. Not all > out of tree modules adapt to 2.6 gracefully, and not all provide a clean > way for building with make-kpkg and produce a clean debian package. > > Just doing make modules_install as root may be easy, but it is _NOT_ the > debian way, and should be frowned upon. > > Furthermore, the user need often to rebuild said modules for his own > system, which needs some infrastructure (ideally a full unpacked kernel > source, configured for the kernel flavor he uses) to be built.
Well, a proper out of tree module can be made into a debian kernel-patch- trivial, so having something that nicely compiles out of tree for those who want it and a DD caring enough of it as debian package would suite everyone. Well, except for those who think it magically belongs into kernel-image- for a single architecture. > > There's a bunch of legacy filesystems that are indeed buggy and haven't > > been updated. I wouldn't compile those into a kernel for any > > architecture, though. > > So, you can't make presence in the kernel source a guarantee for > quality. And i was not speaking only about filesystems, but also about > hardware drivers. I also remember some time when HIGHMEM was buggy on > power3, or when cpufreq was broken on non pmac powerpc. Of course I can't gurantee anything. But your argumentation is like because there's criminal who escaped from prison we should free all of them from. > > The statement above was in reference to the orinoco and asfs patches. I > > see it hard to arue you need them to install, and afterwards you'd be > > much better served with a kernel-patch- patckage for either patch that > > you can maintain, and people can apply on all architectures if they feel > > interested in it. > > Huh ? Did i say that ? I believe it is more sure to have them tested on > one architecture it is used most, before unleashing it on every > unsuspecting architecture, most of them it was never tested on > previously. So make that kernel-patch- ppc-only for the time beeing and ask for testers. Or just send an anncouncement for damn fs to lkml and -fsdevel to ask for testers. That way you'll certainly reach a broader base of people than those using debian kernel images and actually finding out it's included, givent that you don't even mention that anywhere in your documentation. > So, what did i say. It is the responsability of the arch maintainer to > be compatible with the centralized kernel-source package, but there is > no way we will take responsability for compatibility with any random > patch not packaged outside the kernel-source package. Exactly. And the best way to make sure it works is to not keep the amount of source differences very very low. e.g. asfs suddenly breaks any new filesystem that adds to fs/Makefile or fs/Kconfig in the matching area. But strangely only on powerpc while for all other architectures it'll apply. With your attitude of I include what I want, not what's ppc-specifc you cause maintaince pain for other people's packages. > > > Because most x86 > > > users use mostly proprietary drivers to achieve the same thing ? > > > > Huh? I use exactly the same orinoc drivers on ppc and x86, usually > > just upstream but when I need snooping I know where to look for the > > patches. > > See. So, you could take the responsability to test the orinoco patches, > and if they also work for you, it would be easy enough to migrate them > from the popc package into the kernel-source package. I've tested them (although that was a different set of snooping patches, there's lots of those around), and then talked to the orinioco driver maintainer on irc why they aren't in. He explained in more detail than I could unserstand why he thinks the patches are not okay and he doesn't like to see them merged. Ergo, they shouldn't be in a debian kernel-image either but in some kernel-patch- so we can still forward orinoco bugs upstream easily and people wanting to use snooping know they use an unsupported patch. > And most modern wifi cards come with binary only drivers. What do you > plan to do about this ? Buy one that doesn't. At least intel and prism54 have sane free drivers. For now the 11Mbit net is enough for me anyway, but that starts to get really offtopic. > Ideally i would see the patches organised as follow : > > -> the official kernel source tree. > > -> 'official' debian patches. Ok. > > -> per arch port patches. I'm not sure why these should be different from 'official' patches. Of per-arch patches those who don't touch other architectures' code (arch/$ARCH, include/asm-$ARCH, per-arch drivers) can go into the generic code, checked in by the arch maintainer without needing to discuss them. All per-arch patches that do not fall into that category should be discussed on debian-kernel and either they are safe enough to be applied all the time or they'll be applied only for the arch at the end of the patchkit. > The two latest being maybe dvidied between official and eperimental > patches or something such. A subversion repository would make migration > of those among these different patch pools quite easy. I'm not sure the debian is the right place for this exerimental thingies, otoh there's some precendes with things like gcc-experimental or mozilla-snapshot. But if people want a playground under the debian umbrella (which I'm not really in favour of) this should go into a separate svn branch and built as a kernel-experimental package that doesn't e.g. get support from the security team. > Well, welcome to the world of non-mainstream users. So, build yourself a > kernel with said patch, and if it works, fill a bug report against the > kernel-source package to have it included, and another (or the same) > against the powerpc kernel package to have it removed. What is so > difficult with that ? This is the way debian works, and it has done > rather well these past 10 years. That's exactly what I'd like to avoid. the sparc pcmcia patch is for example highly exprimental, not recommended for production use and 2.4-only. It's the last thing I'd like to see in a debian kernel package. (and btw, "my tadpole" above was a made up example, I don't really have on real life. I know people who do, though)