Bug#219582: ITP: linux -- Linux 2.4 kernel
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:
<[🔎] 20031110142352.GB21207@riva.ucam.org>
> 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)
Reply to: