Re: Bug#534866: ITP: kernelcheck -- tool for an automated build of a kernel from the latest source
I sent an email about 2 hours ago, but I guess it didn't go through. So I'll
have to type up a message all over again. That's the last time I use Google
Groups to post to a Usenet group.
NB: KernelCheck no longer refers to a Ubuntu Forums thread.
On Jun 28, 7:50 am, George Danchev <danchev@spnet.net
<mailto:danchev%40spnet.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: