Re: [wli@holomorphy.com: Re: NMU: kernel]
On Mon, May 24, 2004 at 04:08:33PM +0200, Christoph Hellwig wrote:
> 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.
Ah, but it is particularly those that complain about not cleanly
applicating patches, and i would say they have less priority than per
port patches and it is their responsability they build on top of the per
port patches.
> > > 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
I don't read lkml anymore, i even erased my archive, once i noticed that
mutt was not anymore able to handle it.
And how about ppc-only should it be ? Any different than the ppc patch
we have now ? About the announcement, that would be the responsability
of the author of the patch, no ?
> 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.
Well, let me assure you that i am actually reaching _all_ the users who
care about this particular patch.
> > 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.
Well, you have it the wrong way around. If a random filesystem is added
to the kernel-source, it will break the powerpc patch, and i will fix
it. Now if a random third party filesystem is broken on powerpc, too bad
for them, and i don't see how the situation is any different than having
a kernel-patch-sfs and a kernel-patch-randomfs conflicting with each
other.
> > > > 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.
Well, i believe that what should be in a debian kernel, and more to the
point a debian per-arch kernel, is different than what should be in the
mainstream kernel archives. It all depends on who is going to take the
responsability for it. And some upstream authors are over cautious.
> > 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.
And do they come in ibook/G4 airport format ?
> > 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.
Well, the per arch patches should be the responsability of the per arch
maintainer, which let's him react to the per arch bug reports in a
quicker way, thus gaining flexibility and quickness to respond, and
later be moved to the official debian pacthes, which are those that are
in the kernel-source package, if it is felt appropriate.
> 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
A, sure, but the difference is that if let's say i am experimenting a
patch for some obscure subarch, and i don't really have a control over
who will test it or not, i could be bringed to do many new uploads to
debian/unstable of small changes, and once they stabilize, they go into
the kernel-source package or whatever.
Remember, this is debian/unstable, not stable, so we need this
flexibility. If for a given arch, the patch set will be empty or almost
so, then so much the better, but let's not lose that flexibility if
possible.
> 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.
Thus adding an additional layer of bureaucracy on top of a perfectly
working system. Let's just add them to the per arch patch, and then
discuss them with an existing example. Once it is discussed, it can be
moved out again, or whatever, but in the meantime, the user get to
benefit from the patch, and test it.
> > 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
Then just name it with a more politically correct name or something.
> 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.
Yeah, maybe, but still, if you change the name of it, maybe it would be
acceptable, maybe it is not needed, who knows.
> > 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.
So, don't include it, where is the problem. Now if the sparc kernel
maintainer thinks differently from you, he is the one going to take the
responsability for it, so ...
> (and btw, "my tadpole" above was a made up example, I don't really have
> on real life. I know people who do, though)
Sure, i also know powerpc/apus users, i probably also know all of them,
and can probably count them on the fingers on one hand, so ...
Friendly,
Sven Luther
>
Reply to: