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 limits. > 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpMwGIkSHSxk.pgp
Description: PGP signature