Hi, On Mon, Sep 13, 2004 at 04:42:52PM +0200, Thorsten Leemhuis wrote: > Am Sonntag, den 12.09.2004, 21:51 +0300 schrieb Ville Skyttä: > > There are various practices around about where to install extra kernel > > modules, I thought I'd throw in a quick RFC about what people think is > > the best practice, and why. Some alternatives off the cuff: > > > > 0) Somewhere directly below /lib/modules/$uname, in a per-package > > subdir. > > 1) A suitable location below /lib/modules/$uname/kernel. > > 2) /lib/modules/$uname/updates, mirroring the dir structure from > > /lib/modules/$uname/kernel as applicable. > > 3) Same as 2), but s/updates/$something_else_than_updates/. > > 4) As long as it Just Works(tm), does not matter. > > 5) Insert your favourite here. > > 1) IMO shouldn't use "kernel" for stuff that is not included in kernel > > distributed by the kernel vendor. > > I don't think it's a problem. I think installing the module exactly at > the same place where it normally would have been installed when you > compile it also has a lot of benefits. You never know what the next kernel upgrade will look like (look at firewire), the vendor namespace should be left alone, so that no unnecessary migrations and specfile editing occurs. It is just like the case of /usr vs /usr/local or perl's perl/vendor/site hierarchies, where you mirror the substructures starting at different tree starts depending on origin. -- Axel.Thimm at ATrpms.net
Attachment:
pgpZMFuieYlQX.pgp
Description: PGP signature
