Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
#include <hallo.h>
* Robert Millan [Fri, Nov 07 2003, 09:58:57PM]:
> > Out of those 19 kernel-image-* packages and more kernel-module*
> > packages, how many would go away with your proposal?
>
> 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?
> > Do you offer
> > some way to address the binary incompatibility between variants of one
> > architecture -- for example, 386 vs 686 SMP vs AMD-64 kernels?
>
> 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. But, as said,
the ideas are NOT NEW, visit http://debian.linuxwiki.de/DebianKernel/Plan !
> > 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?
> > 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?
> > There are many packages because they address different users' needs.
> > So far I have seen only handwaving and hope to suggest the number or
> > complexity will be reduced in practice.
>
> 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.
> 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).
> As a maintainer, I test all my packages on i386 before uploading on unstable. I
> don't test them on non-i386 unless there's a special reason to do so, and don't
> plan to do it regularly untill I own a non-i386 box myself.
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? 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).
> However, this is offtopic on this discussion.
No, that is exactly the point.
> > It seems like those could be solved with a simple virtual package
> > provided by kernel packages. This is one case where versioned virtual
> > depends would be useful. Having all versions of the kernel use the
> > same package name, though, will be error-prone during reboots. How
> > would I have both linux-kernel-${old} and linux-kernel-${new}
> > installed and bootable, so that I have at least one known working
> > kernel? It is easy to roll back standard packages (except, perhaps,
> > dpkg). It is not so easy to roll back the kernel.
>
> 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?
MfG,
Eduard.
--
Alte Männer sind gefährlich, ihnen ist die Zukunft egal.
-- George Bernard Shaw
Reply to: