Bug#219582: ITP: linux -- Linux 2.4 kernel
Robert Millan <zeratul2@wanadoo.es> writes:
> 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.
So far I have not seen any situation where the benefits will be both
noticable and reliable. In the case of some benefits, your target
audience remains indistinct. In the case of other benefits, you
release untested code for critical system components. In the case of
every benefit, your ITP shows more zeal than foresight.
>> 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.
You do not understand. I specifically mentioned what that features
were so that it would be clear it's not mandatory per upstream: It is
mandatory for Debian's current user space ABI. Specifically, many
applications use native floating point support, and glibc uses
486-specific instructions for locking.
Before you say "the real solution would be to get upstream not
excluding that emulation from SMP" think about why they are exclusive.
>> 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>
The solutions listed there involve leaving ~36 MB of old files on the
user's system indefinitely, without them being tracked by dpkg.
Someone already objected to this -- it defeats the point of a
packaging system. Those solutions don't even pass the sniff test, so
I am surprised you raise them as serious suggestions.
>> 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.
Perhaps I am being dense, but what does "merge their changes" mean
except to customize their kernels?
>> 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).
You claimed that the autobuilder will help when security patches
become available. You can either claim to apply those patches quickly
(more quickly than they are currently available) or claim that the
porting teams will provide tested patches that you just integrate. To
claim both is inconsistent, and such shoddy thinking does not inspire
faith in your ability to integrate these patches.
>> 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).
That does not answer my question. Right now, the current kernels on
arm are 2.4.19 and 2.2.19. On x86 and mips, 2.4.22. On m68k, 2.4.20
and 2.2.25. On sparc, 2.4.21 or 2.2.20 (depending on subarch). On
s390, 2.4.19. Out of six architectures I checked, only two pairs use
the same kernel version. As someone else observed, you may as well
just put Architecture: i386.
>> 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.
I thought one of your complaints was that autobuilders cannot build
the current kernel packages (the whole security patch issue). Can
they or can't they?
>> 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.
You keep raising this (particularly stupid) defense. Except for
XFree86 and glibc, I do not think any Debian package (or group of
packages) has so much code that differs between architectures -- not
just upstream but in the patches Debian applies to it. Neither of
those have such different upstream trees to merge. You simply cannot
claim to be like the rest of Debian packages when there are so many
significant and relevant differences.
Michael
Reply to: