Re: using boost headers
I appreciate your comments
On Sat, 18 Aug 2007, Neil Williams wrote:
On Sat, 18 Aug 2007 14:10:39 -0500 (CDT)
Carlo Segre <segre@iit.edu> wrote:
One of my packages uses the boost headers and distributes them in the
original tarball. I have been modifying the configuration scripts to
ignore the local copy and use the libboost-dev dependency instead. Since
these are headers and not real libraries, would it violate policy for me
to revert to the version included in the tarball?
Potential problems:
1. file collisions. Make sure the internal versions are installed as
package-specific libraries, NOT into /usr/lib/ directly.
The boost libraries are simply includes, no binary libraries are included.
It is reallly not a "library" in the traditional sense.
2. Wasted archive space - your packages simply duplicate existing
archive code.
That is true although until now I have not wanted to alter the original
tarball just not use the included headers.
3. Ditto wasted installation space.
Not really since there are no binary libraries associated with it.
4. The most important reason: The copy of the boost libraries in your
internal code is NEVER going to get the level of inspection and testing
conferred upon the standalone package. Your code will stagnate, it will
harbour bugs fixed in the external version. In short, it will suffer
bit rot. This should be avoided at ALL costs.
Agreed but again, they are includes and so will only influence the
binary of this particular package. In some senses it is analogous to the
author rewriting functions and putting them in his code instead of using
someone else's.
If there is *any* prospect of your code being used in an embedded
environment, you should expect (and support) the reintroduction of the
external dependency to allow use in systems that have clear resource
limits.
not really an issue since this is not a shared library situation, just
includes.
Upstream prefers to
continue distribution in the tarball and it would avoid having to
continually patch the configuration scripts.
Unless there is a CLEAR problem (i.e. RC bugs), I would strongly advise
AGAINST following the upstream 'advice'.
The reason we have a debian/ directory is so that Debian can have a
package that meets Debian requirements. So it causes you a bit more
work? I don't care. Do the right thing and do the work or orphan the
package and let someone else do it.
This is the thing aobut boost, it is not a library but basically a set of
functions taht gets included in your program. I am far from a C++ expert
but this seems to me to be not as clear cut a situation as a binary
library or even Perl modules, where it is very clear cut that the Debian
package is the right way to go.
Let me put it this way:
I would refuse to sponsor your package UNLESS you can demonstrate to my
satisfaction that RC bugs are *absolutely unavoidable* when using the
external library. This is NOT an excuse for upstream to deliberately
introduce flamebait code that tries to force your hand.
Other sponsors have their own preferences - I think I'll add this to my
own list later.
(Yes, I maintain a library that is in this situation and I co-maintain
an application that ignores the stale internal code and uses the
external library instead. You could say I have some experience of this
as I am the upstream for the library project and 4 other Debian packages
that use it.)
I also have several packages that distribute or want local compilation of
libraries such as PGPLOT5 or per modules. In those cases, I always remove
the ones in the tarball or disable their use. I have done so in this
package too and the only reason I am asking is that boost is such a
different kind of library.
Carlo
--
Carlo U. Segre -- Professor of Physics
Associate Dean for Special Projects, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498 Fax: 312.567.3494
segre@iit.edu http://www.iit.edu/~segre segre@debian.org
Reply to: