Steinar H. Gunderson wrote:
> freecdb does not provide a shared library, even though policy requires
> it to do so. This leads to bugs like #243007 (making vpopmail RC-buggy)
> and possibly others.
>
> If there is some good reason for freecdb not to be a shared library
> (Policy 8.3), at the very least there should be a freecdb_pic version,
> but I can't see any such reason.
--8<--
In some cases, it is acceptable for a library to be available in
static form only; these cases include:
* libraries for languages whose shared library support is immature
or unstable
* libraries whose interfaces are in flux or under development
(commonly the case when the library's major version
number is zero, or where the ABI breaks across patchlevels)
* libraries which are explicitly intended to be available only in
static form by their upstream author(s)
--8<--
The last item very much matches freecdb.
The package consists of two static libraries, each one _less than 4kB_
in size. I see no point in making shared libraries of them, unless a
really compelling technical argument proves I _must_. And even then I'm
much happier just forcing people to migrate to tinycdb, a cleaner
reimplementation of the same idea, called tinycdb; any project that
isn't dead itself, and still depends on freecdb, should migrate to
tinycdb. TinyCDB even gets updated every once in a while.
The only reason freecdb exists is to support software that wants to use
djb's cdb, and it even isn't API-compatible with the newer versions of
cdb. I am upstream for this fork, and am officially stating that freecdb
is _DEAD DEAD DEAD_. Pining for the fjords!
Steinar H. Gunderson wrote:
> freecdb does not provide a shared library, even though policy requires
> it to do so. This leads to bugs like #243007 (making vpopmail RC-buggy)
> and possibly others.
>
> If there is some good reason for freecdb not to be a shared library
> (Policy 8.3), at the very least there should be a freecdb_pic version,
> but I can't see any such reason.
--8<--
In some cases, it is acceptable for a library to be available in
static form only; these cases include:
* libraries for languages whose shared library support is immature
or unstable
* libraries whose interfaces are in flux or under development
(commonly the case when the library's major version
number is zero, or where the ABI breaks across patchlevels)
* libraries which are explicitly intended to be available only in
static form by their upstream author(s)
The last item very much matches freecdb.
The package consists of two static libraries, each one _less than 4kB_
in size. I see no point in making shared libraries of them, unless a
really compelling technical argument proves I _must_. And even then I'm
much happier just forcing people to migrate to tinycdb, a cleaner
reimplementation of the same idea, called tinycdb; any project that
isn't dead itself, and still depends on freecdb, should migrate to
tinycdb. TinyCDB even gets updated every once in a while.
The only reason freecdb exists is to support software that wants to use
djb's cdb, and it even isn't API-compatible with the newer versions of
cdb. I am upstream for this fork, and am officially stating that freecdb
is _DEAD DEAD DEAD_. Pining for the fjords!