[csw-maintainers] Shared library placement proposal

[Philip Brown]

Hi Jonathan,
it's nice to see someone else who wants to think carefully about
ramifications of things.
Some info for you first, and then a new issue that your questions have
pointed out.

Maintainers intimately familiar with stuff, might choose to skip down
to "start of new issue"; however, they are encouraged to give
themselves a refresher on "why we do stuff", by reading the full email
anyway :)



On Wed, Feb 16, 2011 at 7:14 AM, Jonathan Craig <jcraig at opencsw.org> wrote:
> ....
> This is where ubuntu uses a "conflicts with" dependency and only
> allows one development option to be installed at a time thereby
> sidestepping the issue of file conflict.  Could we not also create a
> "conflicts with" dependency?

The reason we don't do this, is as follows:
The concept is that we only keep development packages around, that we
actually *need*.
If it's obsolete, we jettison it.
If it's useful, then it should be installable, along with everything
else in our "current" catalog at the moment.
Everything in the current mirror should be able to co-exist.

Consider the alternative;
maintainer A wants to work on FooSoft, version 1
maintainer B wants to work on FooSoft, version 2.
Both versions are deemed "useful at the moment", so are in our current distrib.

Should maintainer B have to wait until A is done tweaking, before
doing work on our build machines? worse yet, should they have to ask a
sysadmin to reinstall/tweak stuff, before he starts his development?
and then the sysadmin has to put things back when done?

This is not user-(or even maintainer) friendly. So, better to set
things up to peacably co-exist without admin intervention.

Additional retro info, that builds on the above:
we dont keep old, obsolete "dev" packages around.
However, we DO keep old shared libraries around, for as long as other
packages of ours actually need them.
We used to keep an archived copy of the older shared libs, in the
"new" lib package. More recently, we started to split off shared libs
into their own specifically named package. This
has some good benefits.
So, when we only have multi-versions of a shared lib for historical
compat reasons, we may well have in our libdir,
libfoo.so.1.0
libfoo.so.1.3
libfoo.so.1.5
libfoo.so -> libfoo.so.1.5

That allows for compat support, while still giving easy "new dev" use for -lfoo

Keep that in mind, for the actual "new" issue, below

  ------
End of retro info, start of new issue (At least I think it is new.
apologies if I misunderstood)
  ------

Again, this issue is ***only relevant for software with
subprefixes***. This means, software that we have deemed important to
have multiple versions installed, and that those versions somehow
require /opt/csw/foosoft-X/  type subprefixes.

It has been proposed, "oh there's no problem, we can just use constructs such as
  ./configure --with-foosoft-lib=/opt/csw/lib
--with-foosoft-inc=/opt/csw/foosoft-X" type support.

But that will not work cleanly.

A properly written ./configure will use BOTH -L and -R, set to the
--with-lib dir specified.
If they are both set to /opt/csw/lib, then it will potentially use the
"wrong" version, if an older version of the shared lib is desired.
(remember, /opt/csw/lib/libfoo.so always points to
/opt/csw/lib/libfoo.so.latest)

If on the other hand, both -L and -R are set to /opt/csw/foosoft-X/lib
... well, then the older version of the lib in /opt/csw/lib, whether
"real" or symlink, will never be used, and we just completely wasted
our time in putting it in /opt/csw/lib in the first place.

Now yes, in theory, we could set **by hand**,
-L/opt/csw/lib/foosoft-X/lib -R/opt/csw/lib
But really.. why should we implement a policy that causes us to fight
installers by hand like this?
Seems like we need to adjust the policy some more. Or perhaps
reconsider its usefulness :(