Re: libcwd: one or two packages?
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 <carlo@alinoe.com>
*)
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?
Reply to: