[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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: