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

On linux kernel packaging issue


I've read (a part of) resent kernel ITP flamewar.
The more I read, the more it frightens me.
Seems that someone without any sort of complete knowledge of the problem,
decided to maintain one of the most important parts of the system. And the
way he chooses is "removing everything that I don't undestand". This looks
like a disaster.

Unlike most other packages, kernel is a piece of software thar *NEEDS* to be
customized in a huge number of situations - even when speaking about x86
only and not taking the other archs.
This situation derives from the nature of kernel development. There are many
different (and fundamentally incompatable) kernel flavours. There are many
off-tree hardware drivers that require kernel patching, and such patches
are hardly compatible. And without such patches kernel WILL NOT WORK for
people who have that hadrware. And with such patches kernel WILL NOT WORK
for people who don't have that hardware.

Optimization is a serious issue too. Unlike most user space software, using
386 kernel on modern PC will cause serious performance loose. Especially if
you consider mmx/sse/... and SMP issues. Note also that not all drivers are
compatible with SMP, etc.

Currently Debian has the most advanced kernel packaging tool available -
make-kpkg. Having read several pages of documentation anyone can build a
packages for customized kernel, and those packages will integrate nicely
into the system. Without such tool, admins will have to eiter install
kernel in non-package form (which is obviously a bad idea), or to do
low-level package creating work themself (which is a huge waste of time).
Welcome to Red Hat ...

For those who don't know the details of kernel world, Debian currently
provides a kernel for each major x86 subarchitecture. This is NOT
confusing, unless a user is a complete idiot. Even more, this is THE ONLY
RIGHT WAY TO GO, and least with the existing kernel codebase.
And if user does not know what CPU he has, and finds it too difficult to
look info /proc/cpuinfo, he should not touch the kernel at all! If
supporting this sort of users is your goal, you should write wizard-style
tool that selects appropriate kernel package for the user.

Curently, it is possible not to bother about local building of the kernel in
many situations - just install the correct package. If optimized kernels
will disappear, local kernel builds in most situations will become
REQUIRED, making admins to spend time on it instead of doing positive work.

Please please please don't break the excellent working system! There are
enough examples in other Linux distros of what that causes!

Please please please don't go the Windows way - "let's make it usable for
dummies at the price of making it hardly usable by experts"!
The saying is: "Create a system that is usable even by idiots, and only
idiots will use it".

If you believe there are serious drawbacks in kernel package management,
please write a text that describes them, propose your solutions, and let's
discuss them. But not just by ignoring the complete problem by removing all
those kernel-* packages! Each of them exists because there is a situation
where it is needed. Unless you have an alternative solution for each and
every of those situations, and technically experienced people agree that
the problem really may be solved that way, you SHOULD NOT remove any single

Please please please don't break Debian !

Reply to: