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

[Philip Brown]

I will preface my email, with the general premise: "Life is not simple".
It would be lovely if there were a nice clean way to deal with this...
but lets face facts, rather than to deny them. There Is No simple
clean automated, "always applies" solution to this.

That being said, lets move on to discuss what Can be done, in the face
of life's messy realities :)



On 9/29/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> ....
> file=opt/csw/lib/libavcodec-0.4.9-pre1.so pkgname=CSWffmpeg
> expected=['CSWlibavcodec-0-4-9-pre1']
> file=opt/csw/lib/libavformat-0.4.9-pre1.so pkgname=CSWffmpeg
> expected=['CSWlibavformat-0-4-9-pre1']
> file=opt/csw/lib/libpostproc.so.0.0.1 pkgname=CSWffmpeg
> expected=['CSWlibpostproc0', 'CSWlibpostproc-0']
>
> With these three, I don't know myself - does it make sense to separate
> these 3 libraries?  Two of them seem to have the version in sync, but
> the version is entangled with the library name, instead of being
> located after the ".so" bit, where nature intended.
>

This is exactly the sort of thing I envisioned running into. Thank you
for doing the hard research to dig up a specific example.
This example is extra complicated, since there is NO SONAME to any of them.
interestingly, though, there is a cross-dependancy in the libs themselves.
libavformat needs libavcodec.
Interestingly, however, it needs, by name, "libavcodec.so". no rev.

So in this case, it would serve no purpose whatsoever to split the
libraries out from the main ffmpeg package, or to split them up
independantly. A newer version of the package will transparently
update older versions, it would seem.


I think you might do well to go with my original theory, slightly expanded:

Unless you find a shared object, of filename "lib*.so*", AND it has a
"SONAME", AND that name has a double-numeric rev  (eg:
libfoo.so.#.#), then you should just leave it alone.