On Wed, Oct 6, 2010 at 9:42 PM, Maciej (Matchek) Blizinski <[email protected]> wrote: > (Phil wrote) >> 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 did explain this previously, but I'll repeat myself for this case) It has been my experience that libraries with only a single digit signifier in the SONAME, tend to respect backward compatibility, and the value of a stable API. They tend to not ever change the SONAME, unless the major version of the associated program changes. in which case, there's no reason to split out the shared lib even more, if it was not normally done so. (note that I do explicitly mean the SONAME. if just the filename has double digits, that doesnt count) In contrast, developers who put in the minor rev number to the SONAME, are practically announcing the fact of, "We have no respect for consistency across major version numbers. We are specifically intending to introduce incompatible features in minor revisions of the program" Hence why they have gone to the extra trouble of putting in the minor rev number into the SONAME. summary: single-digit SONAME implies long term stability. double digit SONAME implies frequent change, and thus a very good reason to split out the lib for dependancy purposes. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
