On Mon, 6 Dec 2010, Troy Dawson wrote:

> dkms
> - For SL6, we have been asked by the scientific community, to not duplicate 
> packages found in the main external repositories (epel, rpmforge, ... ), 
> unless there is a valid reason.
> Both dkms and ndiswrapper have come up as packages that a person might need 
> to get on the network in order to access the repositories.
> But if we are to add drivers to the distribution so that people can access 
> these repositories, I would like them to be in the format that elrepo has 
> them in.
> So I would like to not add dkms, unless there really isn't a better way to 
> get network drivers installed.

Seems fine as long as SL doesn't ship any packages which require dkms,
but ...

At present SL includes dkms so any repo which ships a package which 
requires dkms only requires SL packages. If you don't ship it then
each of epel, rpmforge, ... (and perhaps also vendors who ship 
private device drivers) will have to ship their own dkms with the 
possibility of conflicts or require a package in someone else's
addon repo.
This is of course true for any package but is especially worrying
for a package that is a dependency for kernel addons.

Of course the correct answer would have been for TUV to have included
dmks :-(

-- 
Dr. Andrew C. Aitchison		Computer Officer, DPMMS, Cambridge
[log in to unmask]	http://www.dpmms.cam.ac.uk/~werdna