Re: [wli@holomorphy.com: Re: NMU: kernel]
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)
Reply to: