Bug#219582: ITP: linux -- Linux 2.4 kernel
On Fri, Nov 07, 2003 at 03:19:20PM -0500, Michael Poole wrote:
>
> This is a meaningless observation in the context of how the package
> should be structured.
You said before:
"I have never been confused by Debian's \"normal\" Linux kernel packages."
I understand the confusion in the current structure is not meaningful to you,
but that doesn't mean it isn't meaningful for people who are actualy still
confused with it (like me).
> 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).
(I assume by "go away" you mean "not use in your package", since I don't intend
to replace the current package set.)
> 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.
> 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).
> 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.
> 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..
So if you're one of such users, just don't use my package.
> Non-i386 users regularly get burned by upstream bugs. Is it really a
> good idea to automatically extend that to Debian's users? There was
> just a heated discussion about the desirability of autobuilding
> packages, and if I recall correctly, the consensus was that
> maintainers should build *and test* their packages before inflicting
> them on unstable.
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.
However, this is offtopic on this discussion.
> 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.
--
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: