[elrepo-devel] [rhelv6-list] ELRepo support for RHEL6

[Jon Masters]

On Mon, 2010-12-06 at 00:25 +0000, Phil Perry wrote:
> On 05/12/10 20:33, solarflow99 wrote:

> ELRepo specialises in a very small niche of kABI-tracking kmod packages 
> aimed specifically at backporting updated kernel drivers for enhanced 
> hardware support. This could be backporting a driver from upstream that 
> provides functionality otherwise missing in RHEL (for example, DRBD in 
> RHEL6), or providing (backporting) a newer version of an existing kernel 
> driver that might provide a bug fix or support newer hardware revisions.
> 
> ELRepo is not necessarily designed or intended for widespread usage. In 
> an ideal world all your hardware will just work with RHEL. If the 
> default kernel driver works for you then you should use it. It is only 
> when it doesn't that you might need a package from ELRepo and even then 
> we hope our packages eventually become deprecated as and when such 
> functionality gets backported to future RHEL kernel releases.

I see (RHEL) community value in ELrepo. It's not supported by Red Hat
and clearly a separate effort but it does help a certain subset of users
(particularly those who like to track the latest upstream pieces). From
my end, I am interested in standardized approaches to driver packaging
and distribution. I am interested in making sure that we have a common
approach to packaging that can be used by third parties if they choose
to do so. There is both a Red Hat Driver Update Program (which itself
means more about certain drivers RH packages and ships) but also
packaging infrastructure usable for building drivers in general.

The bottom line is, I would like to help ensure good practice when it
comes to packaging drivers, so that if people are choosing to package
certain things outside of Red Hat, mechanisms and scripts such as those
provided in the Red Hat Driver Update macros, etc. are used (as you are
working on) in order to ensure there is one common way that such things
are done rather than everyone having their own scripts and process. I
would love to help with general packaging advice and best practice,
while leaving the actual packaging of specific drivers and such to
yourselves as your own third party effort :)

Jon.