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
