On Mon, Nov 10, 2003 at 09:29:58AM -0500, Michael Poole wrote: > 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.
I don't have to do that. My package is worthy as long as the advantages outweight the disadvantages in some situations, but not exhaustively (i.e, for every situation), since I'm not replacing the current ones. > 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. Well, my package will be built in the way that supports a wider number of CPUs. Both building for i386 without SMP support and building for i486 with SMP are viable options. However, the real (long-term) solution would be to get upstream not imposing mandatory features for 386. > 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. I just explained that in my response to: <[EMAIL PROTECTED]> > 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? The use of "build their own kernels" is ambigous here. My target audience excludes those who costumise them (apply patches, sub-arch optimisation, etc). It doesn't exclude developers who want to compile my package the standard way in order to change it and merge their changes. I.e, the same that happens for the rest of packages in Debian. > 4) Another benefit you claim is that people on less commonly used > architectures can get autobuilt kernels in the case of security > patches. Not exactly. It shocks me that you ask this because it was actualy in a reply to you: http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html "Handled by autobuilders, [...] This is specialy important for security updates. [...]" I.e: The benefits apply to security updates, but that's not the only updates they apply to. > 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? That question is not pertinent to my package. The same per-architecture team who does porting tasks for the standard Linux package is implicitly doing them for mine (Since they use the same patchset). > 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. I pretend to package all upstream branches (2.4, 2.6, etc). The -defaults package can be selective across arquitectures (like gcc-defaults does). > 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? These scripts already exist. They're called autobuilders. > 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. Just like it happens to the rest of Debian packages. > 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. This is trivial, too. Take my response on System.map, the solution for this would be similar. -- 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)
