#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
