<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 08/05/2011 01:43 PM, Dag Wieers wrote:
<blockquote
cite="mid:alpine.LRH.2.02.1108051937480.4896@pikachu.3ti.be"
type="cite">
<pre wrap="">On Fri, 5 Aug 2011, Alan Bartlett wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 4 August 2011 20:59, Alan Bartlett <a class="moz-txt-link-rfc2396E" href="mailto:ajb@elrepo.org"><ajb@elrepo.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Now another request for your input, please. What should I do with the
kernel-ml-firmware package? If you cannot immediately see the
significance of my question, consider what I had to do with the
kernel-headers for EL5. No doubt our friendly RPM packaging guru, Dag
Wieers, will make a few comments but I would like all of you so
interested to discuss it here, please. If I do not join in the
discussion, or otherwise respond, please be aware that I will still be
following the proceedings with interest. My ultimate choice will be as
a result of your deliberations.
</pre>
</blockquote>
<pre wrap="">
My latest status update.
All is well in the kernel-ml spec file up to and including the one
line following the call of the "clean" macro. What remains to be done?
The requisite "post", "preun" and "files" sections.
Any views on the kernel-ml-firmware package, as mentioned yesterday?
Or do you all intend to give me "free rein" and then criticise what I
ultimately provide? :)
</pre>
</blockquote>
<pre wrap="">
I don't think there's much we can do, like kernel-headers. Either update,
or conflict. But since we don't expect the kernel-ml to be an upgrade
path, I would make it conflicting (and thus a manual step).
There is a big difference between kernel-headers and kernel-firmware in
the sense that newer firmware may not work with older kernels, or older
firmware may fail with newer kernels. But if that's the case it's not
designed very well (the aim is to be able to have multiple kernels that
can be booted at all times, right ?)
In any case, users are on their own so I wouldn't make it easy to install
kernel-ml-firmware (and hard to go back), I prefer to make it hard to
install (and hard to go back ;-)). What do others think ?
</pre>
</blockquote>
I think that is fine as long as it is spelled out what the steps
are. Most people who will be running<br>
a -ml kernel "probably" know what they are doing.<br>
<br>
<div class="moz-signature">-- <br>
Stephen Clark<br>
<b>NetWolves</b><br>
Sr. Software Engineer III<br>
Phone: 813-579-3200<br>
Fax: 813-882-0209<br>
Email: <a class="moz-txt-link-abbreviated" href="mailto:steve.clark@netwolves.com">steve.clark@netwolves.com</a><br>
<a class="moz-txt-link-freetext" href="http://www.netwolves.com">http://www.netwolves.com</a><br>
</div>
</body>
</html>