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

[Maciej (Matchek) Blizinski]

No dia 1 de Outubro de 2010 16:37, Philip Brown <phil at bolthole.com> escreveu:
> 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 :)

Yes, I'm well aware that it's not possible to come up with a simple
rule that humans would agree to adhere to.

> 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.

Yes, libavcodec.so is a symlink:

/opt/csw/lib/libavcodec.so -> libavcodec-0.4.9-pre1.so

I'm not sure what would developers do if they needed to update the
API, but I'm guessing that they would release a new package that would
no longer provide libavcodec.so, but libavcodec.so.1 or similar.  What
matters is the correspondence between the SONAME and the library file
name, and revisions are just a convenient notation for humans.

I don't quite agree with the splitting serving no purpose.  You can
always have a client program needing libavcodec.so, and not needing
other libraries.  Consider this scenario:

/opt/csw/lib/libavformat.so needs libavcodec.so
/opt/csw/bin/foo needs libavcodec.so

At some point, libavformat.so goes away, nothing else links to it.
You want to remove it.  However, it's packaged together with
libavcodec.so, and /opt/csw/bin/foo still depends on it.  If you had
those two libraries packaged separately, you could retire
libavformat.so.

> 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.

I understand and I agree with the first two criteria: It makes sense
to separate the library out, if it is named lib*.so*, and has a
SONAME.  I don't get the bit with the double-numeric versions.  What
matters is the presence of SONAME, and the contents is a conventional
notation, why would any numbers matter?

I'd add a third criterion, which is: It must be in one of the default
search locations, in our case: /opt/csw/lib with optional isalist
subdirectories.