On Tuesday 24 January 2006 20:19, Bernard Li wrote:
> Wouldn't packages like kernel_picker, or SSI, or Infiniband/Myrinet
> which are kernel-specific benefit from being able to probe the OS_Detect
> framework for the installed kernel version, or are they happy with just
> doing 'uname'?
kernel_picker has its own method to find kernels installed. And detecting a
kernel version and using that is just the most naive approach. What if you
have multiple kernels installed? You take the default one? Why is then
systeminstaller setting the system up with at least two kernels?
Before implementing something I would suggest people spend some time to think
about what we need it for and how it should be used. If we don't need it than
leave it out, otherwise this leads to unnecessary bloat. The $id->{os_release}
was misnamed (the kernel is not the OS!) and contained information nobody uses
right now. Besides, there's no readable-perl-one-liner way to provide that
info for images. If someone really needs it, it should be implemented _right_,
that means:
$id->{kernels} = [EMAIL PROTECTED];
$id->{kernel_default} = $default_boot_kernel;
We might have kernel dependent packages, but don't have a framework for
supporting them. Last year I proposed that we should care about this issue,
but there are so many things to do that the plan just evaporated. The minimal
information which can be provided in OS_Detect doesn't make a framework for
supporting kernel dependent packages, yet...
Regards,
Erich
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Oscar-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
