On Sat, 18 Aug 2007 15:24:32 -0500 (CDT) Carlo Segre <segre@iit.edu> wrote: > > 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. So one issue is build-time collisions. What happens if someone wants to build your unpatched package (outside a chroot) and they have the Debian headers installed? > > 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. Then you have a bad situation where the definitions in the headers get out of sync with the libraries being called (as these are external). There are quite enough problems with library transitions without complicating things like that. What are the consequences of using the external headers vs the internal headers? What parts of the package benefit from the internal definitions? > > 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. OK, take a different example: libglib2.0-0 includes time and date handling that is not 64bit-safe (on 32bit systems, glib2 will overrun in 2038) so in libqof1 (which depends on libglib2.0-0), I reimplemented the functions to be 64bit-safe on all platforms. I now have an added maintenance burden of testing and checking that changes to glib2.0 in future don't conflict with my re-implementations. I handle this with a test case upstream and by making my versions quite clearly different (and explicitly supporting conversions to and from the glib2 types within the ranges that are compatible). The easier option would have been to just let my code fail on 32bit systems after 2038 or wait for glib2 to fix that issue (it's not just an issue of whether 32bit is still around in 2038 - we may all be using 128bit chips in our mobile communication devices by then. The problem is that my code is used in financial programs and supports financial forecasts like the ability to calculate mortgages and other long term investments that could fall over as soon as 2013, i.e. 6 years from now). Somehow, I suspect that a LOT of 32bit hardware will still be in use in 6 years, especially embedded stuff. Heck, some of that is still 8 or 16bit. This is what I meant - if you can demonstrate some reason, as above, that makes it a better idea to use the internal code than to use the external code, I'd be happy. What are the differences between the two sets of headers? How will you reconcile differences in future? If the external headers change in areas *other than* the ones that benefit the package (e.g. when glib2 fixes other bugs that are not re-implemented in my code), how easy is it to merge the changes? > This is the thing aobut boost, it is not a library but basically a set of > functions taht gets included in your program. Those functions have to live somewhere. Headers are useless without a .c/.cpp file somewhere. > 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. Whatever is defined, declared or configured via the headers has to actually be called from one binary location and be executed using binary instructions that exist in memory, somewhere. Headers are not compiled so there has to be some C++ somewhere, in a boost library or a standard library, that is being called via the headers in your package and those calls will be changed by the definitions in the headers (otherwise, why worry about the changes at all?). Changes in the external library will change the external headers and when that involves an API transition, your internal headers will be out of sync. That means a FTBFS bug or a series of nasty seg fault bugs. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpHbKmeXZhd9.pgp
Description: PGP signature