On Wed, Jan 02, 2008 at 09:10:28PM -0800, Russ Allbery wrote:
> Bas Wijnen <wijnen@debian.org> 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.
This is true, but this isn't specific to games. Other programs can put
their data, including private shared libraries, in
/usr/{share,lib}/packagename. The difference for games is only that
they may use /usr/{share,lib}/games/packagename instead.
Policy says about this in 10.2:
Shared object files (often .so files) that are not public
libraries, that is, they are not meant to be linked to by third
party executables (binaries of other packages), should be
installed in subdirectories of the /usr/lib directory. Such
files are exempt from the rules that govern ordinary shared
libraries, except that they must not be installed executable and
should be stripped.
The actual subdirectory isn't mentioned, but everyone seems to agree
that it should be /usr/lib/packagename, or a subdirectory thereof. In
case of games, /usr/lib/games/packagename is used, just as it is for
other game data.
> 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.
Well, the piece I quoted above is "something", but it doesn't mention
rpath at all (and the footnote talks about plugins used with dlopen, not
libraries linked with rpath).
The current lintian rpath check will only warn if there is an rpath set,
and it is not set to /usr/lib/packagename. I still think it is
reasonable to expand that to "or, for games, to
/usr/lib/games/packagename". The problem you describe is not specific
for games, but rather a problem with rpath in general. So while it may
be a good idea to forbid rpath completely, and force people packaging
programs which use it upstream to convert the build system to use static
libraries, for example, I don't think this change should depend on that
(well, the changed text would be removed if that is decided, of course).
> I'm going to open a Policy bug on this and block this bug on that one.
Opening a policy bug seems good, but please don't make it
games-specific. I don't think that this bug needs to blocked on that,
because they are two quite different issues IMO ("using private shared
libraries with rpath from subdirectories of /usr/lib" and "games use
/usr/lib/games/packagename for arch-dependent data"). But if I didn't
convince you about that, feel free to set the block anyway. ;-)
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
Attachment:
signature.asc
Description: Digital signature