[RFC] xulrunner, shlibs, and dependencies.

[Mike Hommey]

On Fri, Dec 02, 2005 at 05:52:03PM -0800, Steve Langasek <vorlon at debian.org> wrote:
> On Fri, Dec 02, 2005 at 08:47:47PM +0100, Mike Hommey wrote:
> 
> > As you may or may not know, I'm currently working on packaging
> > xulrunner, which is ought to be the central point for all future mozilla
> > technology, meaning that at more or less long term, all mozilla products
> > (firefox, thunderbird, etc.) will be built on top of it.
> > That will be indeed a great improvment in both memory (who really wants
> > to have libraries loaded twice just because you run 2 of their programs)
> > and security management.
> 
> I think this question is more suited for debian-devel than for
> debian-release, fwiw.  Library packaging is not the exclusive responsibility
> of the release team. :)

Moving there.

> > So my idea is the following :
> > - First, I want to provide the libs with a correct soname. It won't be
> > compatible with upstream until some people use clue sticks, but i'll do
> > my best for them to improve on that point. Having a correct soname will
> > enable us to actually use the shlibs mecanism.
> 
> > - Now, the problem is that we can't really use the sonames correctly,
> > because if we succeed in the clue stick batting, we'll have different
> > sonames, which, in the long term, would be painful. So, I'd like to
> > provide a dummy gecko-x.y-serial or such package, which would correctly
> > depend on the libxul package (with strict version if necessary), and the
> > .shlibs in the libxul-dev package would say to depend on the
> > gecko-x.y-serial package.
> 
> If you don't want to make up sonames (and I think having debian-specific
> sonames is fine, personally), I think that having libxul provide a virtual
> package to use in dependencies is the best option (whether that's
> gecko-x.y-serial, or libxul1debianX, makes no real difference).

Will all the tools resolving the dependencies be fine with a dependency
on a virtual package without one an a real package ? (like for
zlib1g-dev | libz-dev)

> There are two advantages to managing sonames even when upstream does not:
> it lets you interface better with un-packaged software (but *only* if that
> software is built against the Debian version!), and it allows
> co-installability of different library versions.  You need to decide whether
> these features are important enough for your application to warrant spinning
> your own sonames.  (My guess is no.)

My concern is more about what it becomes when we hopefully get upstream
to use sonames. Someone suggested me to use specific sonames like
libxul.so.d1. Does that really work ? Do shlibs work as well with that ?

If this is the case, I think i have my solution...

Mike