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)
