Re: libcwd: one or two packages?
On Fri, 11 Jan 2008, Carlo Wood wrote:
> As is described in
> <URL REMOVED>/libpkg-guide.html
> a shared library should exist of two (binary) packages:
> libfooX and libfoo-dev.
>
> However, the argumentation of that rule is based
> on the assumption that there exist other packages
> that link against those libraries.
> This is not the case for libcwd. Consider the following facts:
>
> - No application (or library) is linked against libcwd
> and then distributed: there will never exist
> (binary) packages that link against libcwd.
If nothing links against a library ever, then there's no point in
distributing it. If something does, then this isn't much of a fact,
since there will exist binaries which are linked against libcwd, and
making those binaries instabuggy is suboptimal.
> - Libcwd itself makes sure that an application that
> was compiled with libcwd version x.y.z, will also
> only be used (runtime linked) with version x.y.z
> (if that is not the case, a message is printed
> and the application core dumps on purpose).
>
> In otherwords, logic dictates that there will be only a
> single (binary) package for libcwd.
That means that any new version of libcwd will automatically make any
packages (or at least, any user-compiled packages) which use it
instabuggy.
Why not use a proper set of sonames for the library and do proper
versioning so people who want to use your library can continue using
it even when a new version is released?
Don Armstrong
--
There is no mechanical problem so difficult that it cannot be solved
by brute strength and ignorance.
-- William's Law
http://www.donarmstrong.com http://rzlab.ucr.edu
Reply to: