[Pkg-mozext-maintainers] inter-extension dependencies and versioning (IPC)

[Daniel Kahn Gillmor]

hey debian mozext packagers--

i've somehow gotten myself responsible for FireGPG, and the deeper i dig
in it, the more unsettled i am by its use of the IPC XPCOM extension.
I'm looking for advice.

A bit of background:

 0) the IPC XPCOM module is an architecture-dependent module; that is,
it needs to be compiled for each flavor of debian.
 1) IPC has been suggested for inclusion in the main XPCOM for something
like 8 years, but has been neither accepted nor rejected in that time
(https://bugzilla.mozilla.org/show_bug.cgi?id=ipc)
 2) Some version of the IPC component is used not only by FireGPG, but
also by FireFTP (not currently in debian) and Enigmail (on
thunderbird/icedove).  It might also be used elsewhere.  i'm finding
that code reuse practices in the moz-ext world are pretty wild-west.
 3) different versions of the IPC component cannot be concurrently
installed.
 4) different versions of IPC will work with different versions of
xulrunner.
 5) IPC itself has been known to have significant API changes.

Since IPC is effectively a library, i'd like to see it implemented in
debian as a library, where possible.  This means i think i want:

 a) only one copy of the source available in the archive;

 b) IPC should be in a separate package from the extensions that use it

 c) the extensions that use IPC should depend on the separate package.

 d) IPC itself may need to depend on the version of xulrunner it links
against.  (maybe we need to be able to build multiple binary packages
during times of transition when two xulrunner-* packages are in the
archive?)

I've started a discussion with IPC developers (mostly Patrick
Brunschwig) about it on the enigmail list:

 http://thread.gmane.org/gmane.comp.mozilla.enigmail.general/13722

Do any of y'all have any suggestions or thoughts about what to do with
this situation?  it seems ugly to me, and i'd be very happy to see
either some ideas about possible solutions, or some ideas about why this
isn't actually a problem.

Regards,

	--dkg

PS Aside from the engineering issues involved here, one motivating
factor is that i'd like to see FireGPG itself become an arch-independent
package.  FireGPG's gmail compatibility seems to be frequently broken (i
think that the gmail webapp itself doesn't present a stable API), and
moving IPC to its own package would streamline the process of rolling
out updates quickly without having to wait for every buildd to do the work.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mozext-maintainers/attachments/20091123/f26f3884/attachment.pgp>