[packman] Linux shared library policy

[Dave Plater]

I'm relatively new to Linux, a friend gave me, I think 5, SuSE 7.3 cds and it was the splash screen on installation showing the staff and 
workplace that really got to me and Win xp didn't appeal to me after 98se. The packaging list would have seen the Packman email I cced 
there about mjpegtools, I was very tired then now my head is clear.

During my period as a maintainer I've learned quite a bit about Linux internals and rules that are applied to the way that packages are 
made up. One of these is the shared library policy which I've seen practical examples of it's necessity. I've also just discovered 
something which appears to me to be a rot setting in the Linux development world or possibly these are two exceptions, one old and one new 
or maybe somebody like me is needed, a fresh "outsiders perspective" from the inside.

I've learned the meaning of ABI (application binary interface), it's the address offset (from the base address the binary is loaded into) 
of the various functions that shared libraries offer to their calling programs. Maybe it's a coincidence that I just happen to be trying to 
turn a new not yet submitted library package into a proper shared library, as I said I lack Linux / Unix experience so please correct any 
misconceptions I have, then my old enemy mjpegtools surfaces as version 2.0.0.
  Both these packages are the "anti openSUSE shared library naming policy" and what appears to me to be a trend to deviate from consistency 
in shared libraries, Mjpegtools appears, from what the developer has said (note appears means speculation not certainty) to have undergone 
a "not small" ABI change and that would mean a bump in the major so version, I've studied libtool and other library build aspects since 
making openCOLLADA and I'm not sure without digging through piles of references but I think libtool can actually detect these ABI changes.

Ok the punchline is mjpegtools's libraries are named thus and have been for at least the last three versions, I've downloaded an entire 
history of mjpegtools source rpms to find out where this came from, mjpegtools supply a spec file which ours is based on, I only use 
supplied spec files for reference nowadays, after I've made an original myself in my own words so to speak :
/usr/lib64/liblavfile-2.0.so.0
/usr/lib64/liblavfile-2.0.so.0.0.0
/usr/lib64/liblavjpeg-2.0.so.0
/usr/lib64/liblavjpeg-2.0.so.0.0.0
/usr/lib64/liblavplay-2.0.so.0
/usr/lib64/liblavplay-2.0.so.0.0.0
/usr/lib64/liblavrec-2.0.so.0
/usr/lib64/liblavrec-2.0.so.0.0.0
/usr/lib64/libmjpegutils-2.0.so.0
/usr/lib64/libmjpegutils-2.0.so.0.0.0
/usr/lib64/libmpeg2encpp-2.0.so.0
/usr/lib64/libmpeg2encpp-2.0.so.0.0.0
/usr/lib64/libmplex2-2.0.so.0
/usr/lib64/libmplex2-2.0.so.0.0.0

The new package I referred to earlier uses, taken from one of the three libraries, "libserd-2.0.0.so.0.0.0" ok this is easy, once I've 
named the libraries container package "libserd-2_0_0-0" for the "untechnical" users, this is why some packages have such strange and ugly 
names. The author of the new package has instructions that this naming is to ensure that his shared libraries future versions can be 
installed in parallel, I've read about this somewhere, oh yes the shared library policy but doesn't that refer to the digits after the 
".so" oh yes that's what they're there for. (I apologise to those of you that don't like sarcasm but it's the only thing I have to anchor 
my sanity)

Maybe this is the root cause of gstreamer never actually functioning 100%, I've switched back to obsolete backend-xine for the umpteenth 
time after trying gstreamer again. One thing I have a wealth of experience with is trouble shooting hardware and embedded program bugs in 
things designed and produced both by myself and by third parties and the worst kind of bug is the type produced by a slight intermittent 
clock jitter or for that matter an infrequent transient from an undefined logic state. Worst still is a part of a program that loses sync 
and enters address space that is undefined but by sheer luck stumbles back into sync, this is actually extreme bad luck if you are talking 
about life support systems or for those of you that value money over life a slot machine  or vending machine. This can go unnoticed for 
ever or irritate the life (excuse the pun) out of the user. Such a bug can be caused by an ABI missmatch, which is the reason why I'm so 
vocal about software using the exact libraries it was built with, I was involved in a heated debate (wasn't really a debate because my 
opinion was ignored) about obsoleting a Packman devel package with a ficticious version number to prevent it from being paired with an 
openSUSE built library package because it introduces an element of uncertainty which to me is an undefined logic state and capable of 
introducing the "hidden bug" I described earlier.

Is this a new trend in the Linux world? Are we eventually going to drop those pesky digits after ".so"? One thing that ms windows and osx 
have going for them is singularity which makes regularity easy, opensource is a collaboration of many spread out all over the world, 
something my generation wanted with a passion when we were young and wanted to unite the whole world in peace.
This is why the shared library and naming conventions are so important, otherwise paths will deviate and confusion will creep in.
As far as the new package is concerned, it's a small package and all three libraries build in one online build service page or the blink of 
an eye. I'm busy learning the "waf" build system, quite good library build support and quite easy to get the libraries in shape. I just 
have to get the named header directories to fit in and allow shared devel packages and then I will, in the best possible way (I would hate 
to be in the position of the debian packager who clashed with Jorge Schilling) present my patches and explain the library packaging 
policies of Linux distributions and how grateful I would be if could call the library containers "libserd0" and not "libserd-2_0_0-0" 
(sarcasm tried to creep in there). If he doesn't want to due to ego maybe, to be a good musician or for that matter outstanding at anything 
you have to have a large ego, I know I've got one myself, I'm a performer and I've dealt with musical performers in the past, in fact a 
large percentage of my acquaintances .are musicians, sound engineers or both, larger than the technical portion. I wonder why I ended up 
maintaining multimedia.

Why has mjpegtools been allowed to abuse library naming. I filed a bug with them thinking it was a problem with the 2.0rc1 version but the 
developer I was communicating with didn't seem to understand what I was trying to say. I'm going to continue to work on patching mjpegtools 
to have correct versioning, it's good practise and the right thing to do in my mind and as I pick up experience I will patch every other 
package I stumble upon that has this disease and eventually be able to build libraries in my sleep, this frees time to do other things like 
fixing somebodies computer, which is where I'm supposed to be now.

What is going on? I'm hoping that those of you who've been around Linux for a while can tell me. If the answer is "it doesn't matter" I'm 
going to relentlessly campaign for a serious change in the openSUSE shared library policy and silently lose faith in the future of Linux.

Now go back up the page and look at the part that says "gstreamer doesn't quite work 100%".  Can somebody please give me a pointer on how 
to detect ABI differences between library versions. I know how to look for bad linking so far, maybe these are just isolated incidents.]

Thanks for your time.
Dave Plater