On 13/01/13 00:25, Paul Wise wrote: > On Sat, 2013-01-12 at 21:44 +0000, Simon McVittie wrote: >> This sounds very familiar. I considered this approach for >> Telepathy, but rejected it because of problems like this. > > BTW, Debian strongly discourages embedded code copies: > > https://wiki.debian.org/EmbeddedCodeCopies
I know, but D-Bus interface XML is pretty far from being code - the closest equivalent that you'd call "code" would be C headers that don't have any inline functions or macros. It can't have bugs other than design flaws and feature requests, and the closest it can get to a security bug is "implementations of this method that obey its documentation can't be secure" (which would still be a bug in the implementation, IMO). > Personally, I think the solution is to merge the specs into the > library source package and drop the specs source package. If there's only one library, this is functionally equivalent; in Debian, telepathy-spec is only provided as documentation. > Unless the specs are used in multiple source packages, then the > solution is the one used by libshr-glib (use Built-Using and don't > ship pre-generated files). Not shipping pre-generated files, sure. Telepathy doesn't do that either; we do the code-generation at build-time. I still think importing D-Bus interfaces from another source package, if they affect your ABI, is actively harmful: it makes the ABI of the current source package depend on an external factor. To make the ABI predictable you'd need a (= something) dependency, at which point you'd have to do sourceful uploads of every affected package in lockstep. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org