[procps] fixing the library

It is probably timely now to make the libproc library follow the normal
rules of what a library should do.

This will actually involve minimal programming.

Currently, the version numbers for libproc follow the version of procps.
When the library is only used by procps programs, this is a little
unnessary but it is ok.

The problem happens when other programs use the library.  They probably
shouldn't of, but they do.  So now we need a better behaving library.
Actually if upstream wasnt so static the problem would occur earlier.

The version of the library should be the ABI version of it. This version
has nothing to do with the release version of procps.  This means, if it
is libproc.so.1 now, and we make a 3.3.2 or even a 3.4.1 then if the ABI
doesnt change, it stays at libproc.so.1  Anything linking to it will
keep working.

If/when we break the ABI, then we bump the version.

My proposal:
To rename the library to libprocfs.so.0.0 with a symlink to libprocfs.so.0
This will mean it is the first minor and release number.

We needed libproc-ng because it was a new version. I don't think we need
the ng.  However libproc doesn't really tell you what it does?
I was thinking as it reads the procfs then libprocfs would be better.

I was also told that we should be using versioned symbols too.
So, does this sound right? To me it will fix this third party linking
that is going on and bring the library up to a real proper library. It
will have its own package in Debian which will help on the multi-arch.

 - Craig
-- 
Craig Small VK2XLZ   http://enc.com.au/          csmall at : enc.com.au
Debian GNU/Linux     http://www.debian.org/      csmall at : debian.org
GPG fingerprint:     5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Other related posts:

  • » [procps] fixing the library - Craig Small