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