Hi! While I generally agree that it's better to keep one version of a library in the repositories, and it's better be upstream version, in case of QXmpp things are a bit more complicated.
First, patch accepting cycle is quite long — we in LeechCraft can't wait for 2-4 months before features get accepted into the upstream branch. We already implement most of the changes we need "on LC side", thanks QXmpp modularity, but sometimes we need to tweak and patch QXmpp's core, as it was with XHTML-IM and In-Band Registration support. And we think of implementing XEPs like Extended Stanza Addressing and Message Carbons soon, and that once again requires as to patch QXmpp core. Once again, LC is a vibrant project, rapidly developing, and unfortunately it cannot be built with upstream QXmpp now (and, I guess, in the nearest future as well). Implementing support for building with both QXmpp versions is hard enough to not being an option. Second, since QXmpp is the primary (and only, for now) XMPP backend in LeechCraft, people around LeechCraft sometimes want to patch QXmpp themselves (I gave Jeremy a link to such patch some time ago), and it's better and more handy for them to do it in already-established community, environment and workflow. One may think that it actually segregates the communities, but actually it's the reverse: it unifies the communities, so in the end QXmpp benefits from code written by LC people. Third, AFAIK there are no packages depending on QXmpp in Debian right now, so one shouldn't worry about binary compatibility issues. Personally, I wish the upstream code could be replaced with the fork's one for now, since that will make things easier for everyone, from users to developers, and I actually don't see any sensible reason for not replacing it. -- Georg Rudoy LeechCraft — http://leechcraft.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
