[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: using boost headers

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.

2. Wasted archive space - your packages simply duplicate existing
archive code.

3. Ditto wasted installation space.

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.

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

> 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.

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.)


Neil Williams

Attachment: pgpMwGIkSHSxk.pgp
Description: PGP signature

Reply to: