RFC: extra kernel module install locations

Axel Thimm Axel.Thimm at ATrpms.net
Tue Sep 14 07:29:12 UTC 2004


On Tue, Sep 14, 2004 at 10:02:32AM +0300, Ville Skyttä wrote:
> On Mon, 2004-09-13 at 13:07, Axel Thimm wrote:
> 
> > OTOH /extras/ (3a above) is what the kernel developers have currently
> > blessed, but the flat structure is irritating.
> 
> Agreed.  But if that has some sort of blessing, I think it would be good
> to either follow the blessed structure, irritating or not, or not to
> install into this dir at all.  I would personally go for the latter :)
> (and just use updates/ for everything at least until extras/ becomes a
> more prominent "standard").

Yes, it looks like this is an area of flux. modutils /upstream) seems
to prefer /updates/, the kernel sources themselves /extra/. Given that
this is a "recent" change (2.6), there is probably still space for
convergence.

> By the way, you used both extra/ and extras/ in your message, I assume
> only one of them is "correct"?

Sorry, the /extra/ is correct. Here is the relevant Makefile snippet
(from scripts/Makefile.modinst):

modinst_dir = $(MODLIB)/$(if $(filter ../% /%,$@),extra/,kernel/$(@D))

A trivial patch would be

-modinst_dir = $(MODLIB)/$(if $(filter ../% /%,$@),extra/,kernel/$(@D))
+modinst_dir = $(MODLIB)/$(if $(filter ../% /%,$@),updates/$(@D),kernel/$(@D))

This would make the kernel sources do the right thing in the sense of
alternative 2).

> It seems that alternative 2 in my original mail (updates/ with mirroring
> the dir structure from kernel/ where applicable) has received most +1's
> so far.

If we feel confident that this is the way to go (aka there are not
objections), we should submit the patch above and see what the
reaction is.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040914/f768051c/attachment.sig>


More information about the fedora-devel-list mailing list