[Pkg-mozext-maintainers] icedove-dev vs xulrunner-1.9.1-dev

[Daniel Kahn Gillmor]

hello mozilla packagers:

i'm looking at ways of building architecture-dependent icedove 
extensions on debian using the new icedove-dev packages.

I notice that icedove-dev ships with many of the same files as 
xulrunner-dev, but in /usr/include/icedove instead of 
/usr/include/xulrunner-1.9.1

possibly even more worrisome, some of the include files seem to differ 
slightly, even in the directories labeled "stable", e.g. 
HAVE_CPP_2BYTE_WCHAR_T is defined in icedove/stable/xpcom-config.h, but 
undefined in xulrunner-1.9.1/stable/xpcom-config.h, and icedove has a 
few extra function defined for nsTArray.h, as well as an 
NS_RUNTIMEABORT() macro in nsDebug.

The above differences are present in stable/ when comparing icedove-dev 
3.0.4-2 and xulrunner-dev 1.9.1.9-3.  There are even more pronounced 
differences in unstable/, or if you compare icedove-dev against 
xulrunner-dev 1.9.1.8-*.

So i guess i'm wondering: for packages that need to compile against 
icedove headers, should the -I flags prefer /usr/include/icedove?  or 
$(pkgconfig --cflags libxul) ?  do we really want both sets of headers 
to exist on the system concurrently?

for that matter, i note that /usr/lib/icedove contains:

  libmozjs.so
  libxpcom.so
  components/libimgicon.so
  components/libmozgnome.so
  components/libdbusservice.so

all of which seem to have other versions available in 
/usr/lib/xulrunner-1.9.1 (or via libmozjs).

is this mini-"dll-hell" going to get us into trouble during the next 
release cycle?  Could it be avoided somehow?

Any suggestions or insight would be appreciated,

	--dkg