Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source
This didn't get attached as a follow-up, so I'll send it again.
NB: KernelCheck no longer refers to a Ubuntu Forums thread.
On Jun 28, 7:50 am, George Danchev <danchev@spnet.net> wrote:
>> You didn't answer my question: can this package be useful to a
Debian user?
> The question could be extended further: ... to be useful to any
distro user?
Yes, and no. Yes, it can be useful. No, only to Debian and it's derivatives.
> In fact, it could be useful if the user doesn't mind to install
kernels on its > own in parallel to the kernels installed by distro
provided packages, or want
to bypass the packaging system for any weird reason. That would lead to
The reason may not be weird at all. Debian provides generic kernel
packages to its users. These generic kernels are suited to support the
majority of Debian's users. But what about the remaining 2-3+%? Are they
just supposed to file a bug and wait months before a new kernel comes
out that supports their hardware? No, because they can easily get a new
kernel another way. Generic kernels can provide either too much, or too
little for a user. Too much, in that a user may not want to sacrifice
boot time because of all the extra modules being loaded. Or maybe
there's a new boot option called 'fastboot' out there. Maybe the user's
TV tuner doesn't work with the standard kernel because the option isn't
enabled in the
kernel configuration. What if someone wants their computer to boot in five
seconds, you can't do that with a generic kernel, can you?
Reference: http://lwn.net/Articles/299483/
> unpredictable and unexpected results sooner or later, and since that
package
mostly tries to ease the build and installation of new kernels for
> unexperienced users, they most probably won't understand the point of
conflict > happening between these two parties installing kernel stuff.
This might also Yes, it could lead to unexpected results. But it's all
part of the process. How does anyone learn anything if they don't make
mistakes? And there shouldn't be any point of conflict, given that
KernelCheck kernels append -candela to the end of each kernel compiled.
Unless Debian decides to append -candela to the end of its kernels,
there shouldn't be a problem. Also, each kernel is independent of
the other. Just because a problem arises under a KernelCheck kernel doesn't
mean that it would still be there under a generic kernel, and vice versa.
lead to spurious bug reports to debian kernel packages and user systems
> rendered unbootable. OTOH, I really doubt that any experienced users
would use > for such a tool to bring latest kernel for them in place,
they just even pull
from git and further take the whole control themselves.
How could there be bug reports on debain kernel packages if the kernels
aren't even named the same? Debian would NOT have a kernel in the repo
with -candela attached to it, as already explained. And why wouldn't
experienced users use it? KernelCheck just automates the process, the
kernel configuration dialog is still there, which is what is used to
configure the kernel. It even allows for custom
patches.
> To summarize: this package could be either dangerous or useless
depending on
the userbase ;-)
Dangerous? Yes, and no. Once again, kernels are independent of each
other. It's not like compiling a kernel is going to do permanent (or
even temporary) damage
to a system. You could also say that gparted is dangerous if you make that
argument. But KernelCheck can't do any harm to a system. You're just
building a package. Useless depending on the userbase? Of course, just
like every other package out there. But it's not entirely useless - The
latest version has only been out 9 days and there are already 300+
downloads on SourceForge alone. (And
I haven't downloaded it at all :))
Last, but not least: this package name sounds quite suboptimal to me and
> should probably be renamed to linuxcheck, since Debian also
distributes other
kernels as well, or to tool could be extended to `check' other kernels
provided in Debian instead, which might be a little nightmare I seriously
doubt worth the effort.
I have mixed feelings about this. At least when people hear 'KernelCheck',
they'd say "Oh, it must check kernels." (even though that's not really
what it does) But LinuxCheck? Mr. John Doe says, "No, I haven't
heard of LinuxCheck, but it must check Linux distributions or something.
I wish there was a program that could compile kernels for me." :)
I admit KernelCheck isn't the best name, but I have a pretty cool logo
for it. The name fit back when I used it to check to make sure I had the
latest kernel up on the Ubuntu Forums thread. But I'm always open to other
names, as long as it doesn't sound crappy like "KernelBuild" or
"KernelCompiler." And I doubt I would ever develop the program to 'check'
kernels provided with any distribution.
~-mk-~
Reply to: