Bug#456318: lintian: rpath check for games should include games dir
On Wed, Jan 02, 2008 at 09:10:28PM -0800, Russ Allbery wrote:
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.
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
signature.asc
Description: Digital signature
Bug#456318: lintian: rpath check for games should include games dir
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]
Bug#456318: lintian: rpath check for games should include games dir
Package: lintian Version: 1.23.41 Severity: normal Lintian checks if files have an rpath set, and warns if they do, unless it is set to /usr/lib/packagename. This is incorrect for games, they would need it to /usr/lib/games/packagename. This means - games get warnings if they don't do anything wrong - games don't get warnings if they put their files in the wrong place There are two possible solutions: - check if a package is in the games section, and require the rpath to be to the correct directory depeding on that. - if this might lead to too many false positives, simply allow /usr/lib/games/packagename rpaths for all packages. Unfortunately I can't provide a patch, as I don't speak perl, but the fix should be applied to the rpath paragraph in checks/binaries, line 216. 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 signature.asc Description: Digital signature
Bug#456318: lintian: rpath check for games should include games dir
Bas Wijnen [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.41 Severity: normal Lintian checks if files have an rpath set, and warns if they do, unless it is set to /usr/lib/packagename. This is incorrect for games, they would need it to /usr/lib/games/packagename. Why? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456318: lintian: rpath check for games should include games dir
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). Hm. Okay. I think it's kind of silly, but I hadn't thought to check the FHS for it, only Debian policy. It's not too hard to add an exception for games. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
