Bas Wijnen <[EMAIL PROTECTED]> writes: > FHS chapter 4, at the end of the paragraph on "Specific options" in > /usr/share, says: > > Similarly, a /usr/lib/games hierarchy may be used in addition to > the /usr/share/games hierarchy if the distributor wishes to > place some game data there. > > Neither policy nor developers' reference say anything about this, but I > think most games choose to use both /usr/share/games and /usr/lib/games > for game data. The good thing about this is that it makes it very easy > to do things to all games at once (exclude them from backups, for > example).
The more that I look at this, the more that I think this isn't a good idea. FHS doesn't say anything about shared libraries, only "game data," which doesn't really sound like shared libraries to me. Putting shared libraries in additional places in the system is tricky and raises the possibility of conflicts between different shared libraries. And putting shared libraries in a location that isn't in ld.so.conf requires setting an rpath, which has potentially bad interactions with multiarch support. That there's nothing in Policy about this is definitely a problem given how often issues about setting rpath come up. I think we need to add something to the binaries section on how to handle rpath. I'm going to open a Policy bug on this and block this bug on that one. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
