<br><br><div><span class="gmail_quote">On 6/25/07, <b class="gmail_sendername">Christopher Blizzard</b> <<a href="mailto:blizzard@redhat.com">blizzard@redhat.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I actually think that we need to capture a small bit of that<br>information.  i.e. kernel, hal, pm-utils and whatnot.  But catching<br>everything?  Probably not really needed for hardware compat.  (Maybe<br>other things like NM, bluez-utils, etc.)
<br><br>Just trying to keep the scope pretty small. :)</blockquote><div><br>Understood,  it just seems to be about the same  amount of codding  work to record everything  rather than filtering stuff out.  Now when you start talking about storage required. . . that is a different story. I think the reason I said it should be on the road map is in the future smolt can help with software compatibility as well.  Again not a high priority given the current scope of smolt, just one for the list.  
<br><br>What may be very valuable from a hardware compat standpoint is a record of packages that aren't in the fedora repos, especially kernel modules.  We know people are going to be installing the nvidia and fglrx drivers, but what else are they installing because the stock kernel doesn't have drivers that do what they want.  
<br></div><br></div>Russell<br>----<br>Russell Harrison<br>Systems Administrator -- Linux Desktops<br>Cisco Systems, Inc.