Re: libselinux version bump past 99

[Paul Gortmaker <paul.gortmaker@windriver.com>]

On 11-03-16 12:07 PM, Stephen Smalley wrote:
> On Wed, 2011-03-16 at 12:04 -0400, Paul Gortmaker wrote:
>> On 11-03-15 08:10 AM, Stephen Smalley wrote:
>>> On Mon, 2011-03-14 at 19:26 -0400, Paul Gortmaker wrote:
>>>> On 11-03-08 05:26 PM, Eamon Walsh wrote:
>>>>> Libselinux has reached version 2.0.99 and I need to push a bug fix, just checking to make sure 2.0.100 is fine and won't cause any problems e.g. with upgrades.
>>>>>
>>>>>
>>>> On a related note, is there a reason why the shared objects don't
>>>> track a similar versioning number?    We came across a situation
>>>> where an internal update added a new dir for libs.   But note the
>>>> shared objects are hard coded to version 1,  and the old selinux
>>>> libs just happened to be found 1st.   Which leads to a cryptic
>>>> internal selinux error message like this:
>>>>
>>>> "libsepol.policydb_read: policydb module version 10 does not
>>>> match my version range 4-8"
>>>>
>>>> Granted, this may not be a common problem, but the solution that
>>>> came to me was to simply let the normal ld.so dynamic library
>>>> versioning do its job in determining which bins need which libs;
>>>> something that it is remarkably good at.  :)
>>> As I understand it, the .so version should only be changed upon an
>>> incompatible ABI change, not upon implementation changes or compatible
>> Sure, and the above error message clearly indicates that
>> this has not been done in the past.   So as I'd hinted at,
>> the question then becomes when to start implementing
>> it, if people agree it makes sense to do what every other
>> library does.
>>
>> The simplest answer seems to be to align it upon the
>> next incompatible ABI change you have queued up.
>> Leaving it hard coded at 1 forever just seems misleading,
>> and causes errors like the one I showed above.
> That's not an ABI change.  The application interface to libsepol did not
> change.

Well you folks are the maintainers in the end and it is your call.

As an end user, the above message didn't really hit home with
me what the underlying issue was, and when I got rid of the
stale libraries, the incompatibility issue was gone.   Whether
it is an ABI change or any other kind of incompatibility is just
going to seem like splitting hairs to the person who can't make
their system work.

I hope you are open to taking advantage of the library version
number in the future, when the opportunity arises.

Thanks,
Paul.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.