Bug#219582: ITP: linux -- Linux 2.4 kernel
Robert Millan writes:
> And even if it was, I claimed my packages has some advantages, but didn't
> claim it doesn't have any disadvantages.
Please explain why the putative advantages outweigh the disadvantages.
1) I haven't built a 2.4 kernel lately, but in linux-2.6, selecting
some mandatory features in upstream for 386 (FPU and 486 instruction
emulation) disables SMP support. How will you build a package for
both 386 and x86 SMP machines? Keep in mind your claim that your
system would get rid of the many kernel-image-* packages.
2) With your packages, how will someone be able to keep a known-good
kernel on her machine when updating from one version of Linux to
another? Complaining that bootloaders have the same problem is
specious: they are considerably smaller, so it's more likely that
changed code paths were tested by the packager. User space also
differs: you can have many system utilities statically linked. If you
have just one kernel installed, though, you better have both rescue
disk and physical access to the machine.
3) One of the benefits you claim is that people can "apt-get source"
to get the source. You have also said that your target audience
excludes those who build their own kernels. To me, this is
inconsistent. What is the target audience for this benefit?
4) Another benefit you claim is that people on less commonly used
architectures can get autobuilt kernels in the case of security
patches. The only suggestion I saw to deal with multi-platform
testing was that some per-architecture team would do that. Who has
volunteered to be on such teams?
5) How will you handle architectures where the current upstream kernel
is not based on the same version as your package? The main suggestion
I see is that they'd have to use the current system for their kernels,
which seems very bad for consistency.
6) Autobuilding from your source package may speed up releasing
security patches. Cannot a similar speedup can be achieved by writing
some scripts (much smaller and less time to maintain) to automatically
build the current kernel packages? Your integration of multiple
architectures will also slow down normal updates, since you have to
get the new package revisions and then resolve any conflicts.
7) #include <System.map.discussion>, but s/System.map/modules/g for
the kernel being replaced. Currently, installing a different version
of the kernel (not just a different revision of the package) makes
both sets of modules available. We should not require users to reboot
so quickly after making a currently safe upgrade: I suspect I am not
alone in preferring to update packages on a different schedule than
when I reboot.
I may have overlooked some of the advantages you claim. (I certainly
hope so, since none of the above are clearly in the ITP's favor.) If
so, please remind me.
Michael
Reply to: