Robert Millan <[EMAIL PROTECTED]> writes:
> There are (at least) the following benefits:
>
> - Easy understanding of the package. Developers looking at the package will
> find every piece in the place Debian packages normaly put it. The binaries
> are in .deb, pristine upstream sources are in .orig.tar.gz, the debian/ dir
> is in .diff.gz
>
> I could finaly work out where everything is, but the current situation is
> confusing. In my apt database, there are 136 packages that match
> "kernel-*",
> from which 19 are "kernel-image-*", 7 are "kernel-source-*", 14 are
> "kernel-headers-*", and 70 are "kernel-patch-*".
This is a meaningless observation in the context of how the package
should be structured.
Out of those 19 kernel-image-* packages and more kernel-module*
packages, how many would go away with your proposal? 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?
Out of the 70 kernel-patch-* files, how many would go away? How will
you resolve the conflicts and functional overlap between patches like
kgdb, grsecurity, lsm, etc?
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.
> - Handled by autobuilders, which means new versions are compiled
> automaticaly
> for all Debian architectures. Normaly, users of non-i386 would have to
> wait untill a maintainer for each port compiles it manualy for their CPU.
>
> This is specialy important for security updates. Remember DSA-358 and
> DSA-336, for which the security team had to build the Linux kernel manualy
> for all our architectures, delaying the advisory?
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.
This becomes even more of an issue if you start throwing more patches
into a common source package, since those patch maintainers will
generally have only one or two architectures to test on.
> - Automatical major updates (the x in 2.x.y). When 2.6 is suitable to be
> the default version, a simple change in -defaults package (ala gcc) would
> enforce updating on all existing systems that use this method. This
> prevents
> us from encountering ABI incompatibility problems, like this recent one in
> Glibc:
> #215010: Illegal instruction with 2.2 kernel
>
> This is not unusual. IIRC, Woody's Glibc wasn't supported by Linux 2.0 (I
> once tried an upgrade from Slink after the Woody release)
>
> Note: as pointed by Andreas, this doesn't apply to minor updates
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.
Michael
