Bug#219582: ITP: linux -- Linux 2.4 kernel
#include <hallo.h>
* Robert Millan [Sat, Nov 08 2003, 12:29:27PM]:
> > > No, I compile without optimisation.
> >
> > In general, you have right. But people expect s super-optimized kernel
> > to be shiped by a distro and you may need an SMP version.
>
> That's not the normal tendency in Debian. People who are really worried
> about optimisation should either:
>
> - Use the current kernel-image-* package set
> - Use apt-src or apt-build
> - Use Gentoo (cough)
Or they found a sane trade-off between optimisations and compatibility
(see Wiki page below which was born in discission!). You did not discuss
it. You took your own ideas as guidelines for the future kernel
development. So please maintain your packages in some personal
repository to not fuck up the name space (don't even think about
experimental tree!) as long as we don't have a consens about it.
> > But, as said,
> > the ideas are NOT NEW, visit http://debian.linuxwiki.de/DebianKernel/Plan !
>
> Thanks. I'll have a look, and consider all of them.
A-Ha. I doubt that you had already the look. You are one man and the
really new philosophy described there needs lots of manpower.
> > > > Out of the 70 kernel-patch-* files, how many would go away?
> > >
> > > All but those I Build-Depend on (i.e, -debian-* and the arch-specific patches).
> >
> > You realize that this will trigger lots of problems? You enforce a
> > kernel upgrade everytime when some patch for a weird m68k box (with
> > maybe 20 users in the world) has been changed?
>
> If I choose to support m68k in my packages, this is something one should
> expect. The same happens in the rest of Debian: You force an upgrade of
> package "foo" everytime when an m68k patch is applied.
>
> If it turns out that it's not worth supporting m68k in these conditions,
> then so be it. I'm not going to fall down because of that.
Your reasoning is flawed. The packages you refer to as examples (gcc,
libc) are maintained buy whole projects. And the do much more testing
and they don't plan to drop parts or whole architectures with the first
appearence of problems as you are going to do.
> > > > How will
> > > > you resolve the conflicts and functional overlap between patches like
> > > > kgdb, grsecurity, lsm, etc?
> > >
> > > I won't. There's a reason why they're not in kernel-patch-debian.
> >
> > So you plan a new kernel package generation and do not have any new
> > ideas to solve existing IMPORTANT problems?
>
> You're thinking of my package as a complete replacement for the way the Linux
> kernel is packaged in Debian, but I think of it as an alternative.
A-Ha. So there will be even more users confused, jumping between the
traditional packages and those from you.
> > > As I said before, my package is not targeted at "power users" who compile their
> > > own Linux kernels, apply their preferred patches, optimise for their CPU, etc..
> >
> > But you should. It is IMO pointless to throw another Linux kernel
> > package which is only oriented to the "cosmetic" wishes of Debian
> > developers.
>
> It's not "cosmetic". The point is it has a completely different packaging
> style and philosophy. I want to package the Linux kernel in the same way
> the rest of Debian is packaged, that's all.
As said above, this may be done this way but with 10 times more testing,
wasting 10 times more bandwith (for frequent useles updates) and 10
times more exotic hardware available all the time.
> If you have more ideas that improve my packages in that field _without_
> breaking its current packaging style and philosophy (which is the whole
> point), they're welcome as I said.
You seem to be keen on pushing "new philosophy" but at which costs?
> > > So if you're one of such users, just don't use my package.
> >
> > Such users can already use Herbert's packages. What's the problem with
> > them _from their_ point of view? (Except of the kinda unsafe initrd
> > integration but that is another issue).
>
> Frankly, I don't know. My packages have advantages and disadvantages, I
> just can't expect everyone to prefer them.
That's why I told you to keep them outside of Debian during the
development.
> > And you want to become a kernel maintainer for 11 arches which will
> > causes unknown number of sub-arches to be supported? You didn't consider
> > that the current arch-dependent kernel-source packages exist for a
> > reason?
>
> What do you mean by "kernel maintainer"? The base patchset is provided by
> Herbert, not me. The arch-specific patches are provided by someone else, too.
I cannot see many of those "someone else" being puzzled so far.
> > You realize that the motivation of maintainers of some other
> > architectures varies and makes your release plans burn to ashes if you
> > relies on them (talk to debian-boot people if you don't believe).
>
> As I said a thousand times, if an architecture is unsupportable, not
> supporting it is an option.
And as said before, your ideas are not consistent. You claim to create a
linux-kernel package for every architecture, but only for that you like.
> > > I don't see why should I address that. The same happens when you update your
> > > bootloader, or sysvinit, or coreutils, glibc, etc.
> > >
> > > My advice: Have a rescue disk at hand.
> >
> > Hear, hear, you wanna sponsor an external CDROM drive for every embedded
> > system in the world?
>
> That's not my problem. The same happens when you update your bootloader, or
> sysvinit, or coreutils, or glibc, etc.
Bullshit. You can fix most stuff with a initrd that includes ash-static
or such. When you fuckup the kernel (and upload without testing as
indicated above), there is no way to fix it unless there is human
operator sitting in front of the box.
MfG,
Eduard.
Reply to: