Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
[ Please keep CC to 219582@bugs.debian.org ]
On Sat, Nov 08, 2003 at 09:08:36AM +0100, Eduard Bloch wrote:
> > All but two: linux and linux-2.4 (which are actualy the same thing. I.e:
> > installing one will bring the other).
>
> Where linux would be a meta-package like the gcc meta-package wich
> installs the "prefered" kernel on each arch, right?
Yes.
> > 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)
> 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.
> > > 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.
> > > 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.
It's not essential for me to support _broken_ patches that conflict each
other, but if you are interested, I welcome your help on that.
> > 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.
It's not my task to propose ideas for optimisation and tweaking, since other
people have already addressed this in a more general way (apt-src, apt-build).
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.
> > 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.
> 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.
> 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.
> > 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.
--
Robert Millan
"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."
-- J.R.R.T, Ainulindale (Silmarillion)
Reply to: