Bug#219582: ITP: linux -- Linux 2.4 kernel
On Sat, Nov 08, 2003 at 06:27:42PM +0100, Eduard Bloch wrote:
> >
> > No, I took the ideas from the thousands of packages in Debian. How many of
> > them provide optimised binaries?
>
> Where do you see an inconsistence in my argumentation? libssl and atlas
> are examples whehere optimisations make sence, there are real jumps in
> performance. I would do the same for the kernel: pure i386 and something
> to make most users crying for optimisations happy (i686 version which is
> good for p2..4 and various k7 steppings).
And Nikita just pointed out there's libc6-i686. It might make sense to add
linux-i686 too. I'm open for discussing that, but this discussion doesn't
belong on the ITP bug.
> > If you want me to provide optimised binaries, then this is you who should go
> > and get the consensus. So instead of drawing your silly threats, bring up
> > some points and I'll gladly discuss them with you.
>
> I did enough. If you did not notice, there are requests for the
> debian-kernel mailing list.
I have noticed, and that's fine. I'll be happy to discuss how the
"optimisation" issue fits in my package scheme, and reach consensus on
what is the proper way to deal with that.
> > The current Linux kernel maintainers, which provide that patchset on which my
> > package is based, don't do any testing?
>
> How do you know that they like your model at all?
That's irrelevant. They provide "kernel-patch-*" packages, and I simply
Build-Depend on them.
> What you you do if it
> takes 2-3 months to make a new kernel release ready for
> $the_exotic_arch? Do you want to make the people wait?
It depends. This is something we can discuss later, but my suggestion is
to support $the_exotic_arch only if it's not detrimental for other arches.
> > And stop using it as an argument. If there are no up-to-date patches for one
> > architecture in Debian, this is a problem by itself. It doesn't have anything
> > to do with my package.
>
> So package it for i386 only. Than you can guarantee that it won't have
> anything to do with your package.
Initialy, it'll be packaged for all architectures supported by upstream. Then
we can discuss wether it's viable to support broken architectures or not.
> > > And as said before, your ideas are not consistent. You claim to create a
> > > linux-kernel package for every architecture, but only for that you like.
> >
> > Erm.. don't put words in my mouth?
>
> Well, think about the words. They are implication of the facts that you
> try to ignore.
Find a quote where I say that I intend to support all architectures even if
some of them are badly broken in upstream.
> > > indicated above), there is no way to fix it unless there is human
> > > operator sitting in front of the box.
> >
> > So, you can repair from an initrd system, but you can't load a backup Linux
> > kernel?
>
> If you expect possible breakage, you can make preparations to rescue the
> system. If someone unintentionaly installs a new kernel just because you
> decided to change the dependency in "linux", this will hit the user
> unexpectedly.
Obviously, the dependency in "linux" would only change when the new major
update ("linux-x.y" package) has been properly tested.
--
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: