97796 2005-07-03 02:40 0000 moduledb of module-rebuild should be in /var/lib instead of /usr/share 2005-07-05 06:42:26 0000 1 1 1 Unclassified Gentoo Linux Core system unspecified All Linux RESOLVED FIXED P2 normal --- 1 betelgeuse@gentoo.org johnm@gentoo.org betelgeuse@gentoo.org 2005-07-03 02:40:09 0000 R_MODULES="${ROOT}/usr/share/module-rebuild/moduledb" /usr/share is only for static data. /var/lib should be used for changing data. If I wanted, I should be able to mount /usr read-only. betelgeuse@gentoo.org 2005-07-03 02:42:47 0000 /usr/share: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA /var/lib: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION johnm@gentoo.org 2005-07-05 03:17:05 0000 that is of course assuming we follow the FHS. Which (strictly speaking) we dont. Will look at this sometime. betelgeuse@gentoo.org 2005-07-05 03:27:40 0000 We don't strictly follow FHS, but I think this thing is followed also on Gentoo. There is a question about this in the end of mentoring quiz (12). betelgeuse@gentoo.org 2005-07-05 03:30:11 0000 I can make patches for this, if you are not interested. johnm@gentoo.org 2005-07-05 04:27:29 0000 fixed in cvs. please try 0.5 shortly. betelgeuse@gentoo.org 2005-07-05 05:41:15 0000 I think you should have moved the moduledb from /usr/share to /var/lib in the ebuild. Now everyone has to repopulate their moduledb and the old moduledb is left as a cruft to the system. johnm@gentoo.org 2005-07-05 06:42:26 0000 I considered doing that actually, but decided to make a clean break away from it. There are two parts to this. the eclass linux-mod and the module-rebuild script. in this case, the eclass handles what should be done re: the moduledb database. if module-rebuild hasnt already repopulated then it moves the old database to the new location. when this goes stable, it would be prefered that we re-populate than to move the original one. in any case, it removes the old cruft.