> Back in the time when I tried three things complicated packaging: The > use of the heavily patched ares library in contrib, the non-stable > ABI/ABI between releases, and the build system. > > The ares case is fixed: I helped to push patches upstream and became the > co-maintainer of c-ares in Debian.
I remember encountering that at the very beginning - I'm glad to hear you've but that problem in it's place finally > To fix the API/ABI problem I decided to package versioned packages like > for example boost does. Parts of my efforts are still available: >> http://anonscm.debian.org/gitweb/?p=collab-maint/resiprocate.git;a=summary > (repository uses topgit) I saw the discussion about this on debian-mentor. Your solution is good, and the API/ABI changes are a non-issue for people on a stable Debian version who only want to use binaries that are built with Debian in mind. Supporting non-Debian binaries should be the responsibility of those who make the non-Debian binaries: they can release alternate versions of their product for each stable Debian release, for example. I'm fairly confident that if a particular version of reSIProcate is in Debian stable, that will also start to impact the way upstream operate in future. As they haven't been packaged on any platform whatsoever, they haven't had to think about this issue. > And with the autotools branch #3 seems to be tackled. Exactly - it also makes it easier to package for other platforms, cross-compile, etc. Furthermore, it removes one barrier for people new to the reSIProcate project, they will no longer need to understand the bespoke build system. _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
