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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
