[csw-maintainers] An idea for a shared libraries policy

[Philip Brown]

On 9/29/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>
> Do we have instances in which we package multiple version of the same
> dynamically loaded object into one package?  I think not, but if we
> had, they could be separated as well.

not to my memory.
The "include older binary versions" issue, usually (possibly ONLY)
comes up for traditional shared libraries only.



>> What about if there are multiple objects in the package?
>
> The idea is to not have multiple objects in one package.  It's best of
> the granularity corresponds to the chunks in which we'll phase out
> shared libraries.  If there are multiple libraries that are to be
> phased out together, they could live in one package.  However, this
> might be hard to predict, so it's safer to have each object in a
> separate package.

There are some things that conceptually should always be grouped together.

For example:
atspi
/opt/csw/lib/libcspi.so.0.10.11
 /opt/csw/lib/libloginhelper.so.0.0.0
 /opt/csw/lib/libspi.so.0.10.11

augeas
 /opt/csw/lib/libaugeas.so.0.10.1
 /opt/csw/lib/libfa.so.1.3.0

boost_rt
 (a BUNCH)

fltk
 /opt/csw/lib/libfltk.so.1.1
 /opt/csw/lib/libfltk_forms.so.1.1
 /opt/csw/lib/libfltk_gl.so.1.1
 /opt/csw/lib/libfltk_images.so.1.1

It would arguably be a mistake, to get into a packaging scheme which
might allow some of these to accidentally get out of sync with one
another.
Ideally, in my opinion, they should remain as part of a single unified
runtime package.




> CSWlibfoo-devel:
> /opt/csw/include/foo.h
> /opt/csw/lib/libfoo.so → libfoo.so.1

I agree, libxxx.so symlinks belong in devel packages. If you split out
a runtime, you dont need the libxxx.so symlink.
(but that's what we do right now already, I think. We just ship the
"real" file, with no symlinks, in our "rt" packages)

Random comment: I think that libraries with SONAMEs that include minor
revs, are more likely to fall prey to the need for splitting out.
In contrast, libraries that have ONLY a major rev:  "libxxx.so.1" -
tend to play nicely and respect compatibility between revs very well.
(and by implication, will probably not need fancy sub-packages).   So
you might go easy on the checkpkg checks, in those cases.