On Fri, Jan 11, 2008 at 01:45:06PM -0800, Don Armstrong wrote: > > - 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.
That is correct. But I didn't say that nothing links with it. I said that there will never be binary packages that link against it (at least, that wouldn't make sense). > 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. Those binary will be temporary executables under development, compiled in the development tree of the maintainer/developer with 'make'. This will not be "buggy" after on such a machine libcwd would be upgraded - it would just require a recompile (run 'make' again). Since such application are constantly recompiled anyway, I think that the argument that the developer can re-run his application under-development five minutes longer before doing a recompile is an argument at all. > > - 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. You already said that, see above. > 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? Because that makes no sense in this case. The usage cycle of libcwd is as follows: 1) (re)install libcwd 2) Add support for libcwd to code (if not already done) 3) Run 'make' 4) Test application 5) Make changes to application 6) Go to either 1 or 3 while developing, otherwise 7) Turn off debugging 8) Recompile without libcwd 9) Distribute application The loop to 1 would be -say- every few months at most. What you are proposing, to distribute a separate package for libcwd would ONLY be so that the developer can skip 3, having reinstalled libcwd. The "benefit" of that, especially since the result would be a COREDUMP (see below*), OR I'd have to release a new NAME every release, stands completely in the shadow of the confusion that the very existance of a binary package would give rise to: namely, that developers think they can (should) write applications that are still linked against libcwd when distributed in binary form! -- Carlo Wood <[EMAIL PROTECTED]> *) COREDUMP : check_configuration: This version of libcwd does not match the version of libcwd/config.h! Are your paths correct? Did you recently upgrade libcwd and forgot to recompile this application? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
