[haiku-commits] Re: r35324 - in haiku/trunk/src/libs/icu: . source/common source/data source/i18n source/stubdata
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 28 Jan 2010 14:44:58 +0100
On 2010-01-28 at 13:04:24 [+0100], Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
>
> On 2010-01-28 at 11:25:15 [+0100], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> 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.
Yup, I suppose the release version should be provided by the package, it's got
nothing to do with the library interface.
> 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.
Ah, I obviously missed the notion of a minor API version. I find that notion a
bit cumbersome, but I guess it makes sense to protect packages depending on a
library from the need to update with minor adjustments to that lib. On the
other hand, that opens the door to unresolved symbols if an app has been linked
against libfoo.so.1.3 and then is being executed with libfoo.so.1.2.
> 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.
Right, that's what I meant by API version. For the current ICU, this is 4.2 (or
42 internally), i. e. that's incompatible with the upcoming version 4.4. So
their major API naming scheme uses two digits :-\
I suppose finding out the exact binary compatibility strategy for all those
libs could become tedious, but I'm afraid there's no way around that. We should
probably peek at OpenBSD, since they seem to have their own library API
versioning, maybe we can lean on that.
> 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.
Well, in your example, the API-version would be '1', so libfoo.so.1 would not
be omitted, it would be the real lib and there'd be a link libfoo.so ->
libfoo.so.1
So which of all these (release, minor API, major API, basename) do we want in
/system/lib and which of them in /boot/develop/lib/<arch>/?
It is no problem to add support for all of them, but that would add quite some
clutter.
I personally favour this setup:
/system/lib only contains real libraries with their (major) API version as
suffix, e.g. 'libfoo.so.1'. No basename links, at least not in the long run
(though we keep them around for a while until all optional packages referring
to libs via their basename have been updated).
/boot/develop/lib/<arch> contains two links for public libraries: one with the
major API suffix and one with the basename, both of which point to the
corresponding lib in /system/lib. If we decide to provide separate ...-devel
packages for development purposes, those would contain the headers and the
links in /boot/develop/lib/<arch>. If not, those links would be provided by the
standard package.
Private libraries do not have any links in /boot/develop/lib/<arch>, so they
are not available for development by default.
Of course, that scheme would not allow support for backward compatibility
between minor API versions.
Opinions?
cheers,
Oliver
Other related posts:
