[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#458824: better specification for when rpath is permitted is needed



On Wed, Jan 02, 2008 at 09:19:17PM -0800, Russ Allbery wrote:
> Package: debian-policy
> Version: 3.7.3.0
> Severity: wishlist
> 
> While analyzing http://bugs.debian.org/456318 I noticed that there's
> nothing in Policy about when binaries are allowed to use rpath.  The
> question raised in that bug is whether games are allowed by FHS to
> put their shared libraries in /usr/lib/games instead of /usr/lib.  But
> more generally, we really need a specification of use of rpath that:
> 
> * Says that binaries must not put standard paths such as /usr/lib,
>   /usr/local/lib, and so forth in their rpath since this overrides the
>   ordering possibly configured by the local system administrator.  The
>   system administrator may want /opt/lib take priority over all other
>   library directories or something (and there are also multilib concerns).

I really have to agree that it's not a good thing that they put
paths like /usr/lib in it.

> * Mentions setting rpath to point to a private directory for a package.
>   Take a clear stance on whether this is allowed for multiple cooperating
>   packages or only within a single package, since this is frequently
>   debated and either it's allowed or it isn't.

I think there are a few cases here:
- It's a private shared lib that's used by a few applications from
  the same source package.
- Applications that can make use of "plugins" which they will
  dlopen().
- There are a whole bunch of modules that come from several source
  packages, but they're all related.  I'm thinking about things like
  for instance R.  It's simular to what perl/python do, but it
  actually has shared objects in it.
  (This might be the same as the previous one?)

I think in none of the cases the library should have an soname, and only
in the first case it should have an rpath.

There is also an alternative to the rpath and that is changing
ld.so.conf, or putting a file in /etc/ld.so.conf.d.  And some packages
seem to be using that.  And I'm not sure if we should encourage or
discourage that.


Kurt




Reply to: