[haiku-commits] Re: r35324 - in haiku/trunk/src/libs/icu: . source/common source/data source/i18n source/stubdata
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 28 Jan 2010 13:04:24 +0100
On 2010-01-28 at 11:25:15 [+0100], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> On 2010-01-28 at 06:37:02 [+0100], Ingo Weinhold <ingo_weinhold@xxxxxx>
> wrote:
> > On 2010-01-28 at 00:14:50 [+0100], zooey@xxxxxxxxxxxxxxx wrote:
> > > Author: zooey
> >
> > I don't ICU's versioning policy with respect to binary compatibility, but
> > just in general, do you plan to generate the respective symlinks
> > (libfoo.so.1
> > -> libfoo.so.1.2 -> libfoo.so.1) as well?
>
> I thought about that for a while yesterday and then came to the conclusion
> that it doesn't make sense to care for anything else than API-version.
> So, if the release libfoo-2.3.2 implements the API-version 2.3, there will
> be
> libfoo.so.2.3 and a link libfoo.so -> libfoo.so.2.3 (but no
> libfoo.so.2.3.2).
> I can't see the point of any "inbetween" versions (like libfoo.so.2), as the
> API is either compatible or it isn't, nor do I grok why some libs on Linux
> are
> distributed with the full release version suffix and then come with two
> links
> (from the basename and the api-versioned name).
> Maybe I'm missing something, but AFAICS having the API-versioned name alone
> would be enough, since the basename link doesn't serve any purpose once all
> packages have been relinked.
AFAIK, the commonly used versioning scheme is the following:
libfoo.so.1.2.3:
The actual library file. This is the third bug fix version since 1.2.0, which
defines minor API version 1.2. It could as well be named libfoo.so.1.2
directly. Exists probably only for clarity. Otherwise the exact version
information would need to be specified somewhere else.
libfoo.so.1.2:
Symlink. 1.2 is the minor API version, i.e. all libfoo.so.1.x.y with x >= 2
will be binary backwards compatible to this version.
libfoo.so.1:
Symlink. 1 is the major API version defining the domain for binary
compatibility. That's also the soname of all 1.x.y libraries. Developers
usually link their apps/libraries against this one.
libfoo.so:
Symlink. Superfluous for libraries that significantly refactor/rename stuff
between major version. For others, like libc.so, that have a largely stable
API subset, that's what developers would link their stuff against.
When I look at my linux lib dirs, I see that generally libfoo.so.1.2 seems to
be considered superfluous. Oftentimes libfoo.so is omitted. Moreover, there's
no symlink chain (libfoo.so -> libfoo.so.1 -> libfoo.so.1.2 ->
libfoo.so.1.2.3) anymore. All symlinks point directly to libfoo.so.1.2.3.
Back to your point: Omitting libfoo.so.1 wouldn't work, since that's the
library's soname. At least, if you want to allow programs linked against 1.2
still to work with 1.3. libfoo.so can be omitted depending on the typical
(developer) use of the library. libfoo.so.1.2 is essentially useless, unless
you don't want to have the full version information in the file name.
CU, Ingo
Other related posts:
