[csw-maintainers] Shared library placement proposal

[Ben Walton]

Excerpts from Jonathan Craig's message of Tue Feb 15 16:21:07 -0500 2011:

Hi Jonathan,

> Cant be done given the existing implementation or cant be done at
> all.  Should we limit our solutions to the existing code if it
> precludes the implementation of a more elegant solution?

Part of the rationale behind this is that we don't currently allow
declaring an I(ncompatible) dependency on a package as a general
principle.  It's really only used when a package name changes to
ensure the old one gets kicked out.  Thus, we don't want to have two
packages owning the same files if they are allowed to be installed
side by side.  As such, checkpkg flags it as an error.

I don't know the original motivation behind this choice and my
personal feeling is the for things like this it actually would make
sense to use it...especially now that the catalog carries this
information.  (If I had to guess, I'd

> Hmm, this is a tough one because its a situation we have as a
> maintainer community that isn't as much of an issue for an end user.

A good point, although users could hit it depending on what they're
doing.

> whatever version of the shared library.  This doesn't solve the
> issue of conflicting include files.  For the build farm could we
> have installation of development packages into private root
> directories that are added to the using -L/-I options but expect to
> find their runtime libraries in /opt/csw/lib using -R.

Alternatives would make a good choice for this if combined with a
private directory (eg: /opt/csw/include/bdb4{6,7,8,etc}) for fallback
-I use...I think.  This could also work for the .so symlinks.

We'd end up with something like:

include/
  db.h.47
  db.h.48
  db.h -> db.h.48 (managed by alternatives)
  db47/
   db.h -> ../db.h.47
  db48/
   dh.h -> ../db.h.48

And a similar layout for the lib/ bits.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302