Bug#219582: On linux kernel packaging issue
On Sat, Nov 08, 2003 at 03:56:03PM +0300, Nikita V. Youshchenko wrote:
> > I made the package in the way I found most consistent and easy to
> > understand, for users and for developers. You're calling me idiot by
> > saying that, so I'll stop here.
>
> I apologize if the above could be understood that way.
> Of course I didn't meant that. I believe the cited saying is well-known,
> so I just cited it. There was nothing personal.
If it is just missunderstanding, that's ok. No offense then.
> Maybe some "problems" may be called upstream bugs. However, we should
> realize that:
> - kernel is absolutely required
> - kernel is extremely complex
> - there are lots of debatable issues inside the kernel
> That means that most of such "upstream bugs" will not be "fixed by
> upstream" in a reasonable time, and we need to use kernel as is.
I realise, and ack there's room for improvement.
> Of course.
> But if a feature is supported now, and you are proposing to remove the
> support, it is definitly a bad idea. Some reasons were described in my
> original posting.
I'm not removing anything. All I do is providing an alternative. If you
don't like my alternative, you may keep using the current scheme.
> "Kernel patch" packages are maintained by different people. No one is
> asking you to maintain them all. However, if you are going to maintain
> "the main kernel package", you should ensure that all those incompatable
> patches will have a change to be usable. Because there are people who
> need them.
You haven't read my initial mail, referenced in the ITP. In that mail I
explain that I'm not maintaining "the main kernel package". My package uses
the patchset from Herbert.
> 1. How with your scheme users will get CPU-optimized kernel on each
> system?
They won't. Just like Glibc maintainers don't provide optimised packages
I don't see why should I provide them.
> Note that CPU-optimization for kernel is not the same as giving
> -fcpu=xxx to gcc - the actual kernel core differs!
That isn't relevant.
> 2. How with your scheme users will get customized kernels installed?
> Now this may be done by downloading kernel sources (from any of several
> existing upstream trees), applying needed patches, and running make-kpkg.
The same way users get customized packages of anything else in Debian: get
the source, add/remove patches, build it.
And with the same disadvantages, of course (which I'm not going to enumerate).
--
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: