[RFC] xulrunner, shlibs, and dependencies.

[Mike Hommey]

Hi

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.

Anyways, the mid-term plan would be to migrate the applications that use
mozilla as a platform (such as epiphany, galeon, kazehakase, etc.) to
build on top of xulrunner (libxul, actually) instead of the current
mozilla, and instead of having a firefox-dev package as requested in
#322521.

I'd like to make everybody's life easier, and would like to improve the
current situation, but I'd like some feedback on my ideas, to know if my
solutions are the proper ones or if I should explore some other ways.

Nowadays, when the mozilla ABI breaks, which happens quite often (though
it is supposed to get better in the future), all the epiphany, galeon
and friends break and need rebuilding with the newer mozilla (if there's
no API breakage at the same time, in which case some changes are needed
in the programs).

In the current situation, the dependencies are quite useless. We can't
really stick to a strict dependency, which would be painful (every new
upload of mozilla would need a rebuild of its reverse dependencies), and
we can't set a >= dependency either, because of the breakage.

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.

The typical scenarios would be the following:
- we have libxul version 1, gecko-1 depending on it.
- epiphany and friends built on top of it would get the dependency on
  gecko-1 through the shlibs.
- libxul upgrades to version 2, which is ABI/API compatible. gecko-1
  will now depend on it.
- epiphany and friends, already depending on gecko-1 would be fine.
- libxul upgrades to version 3, which breaks ABI. now we create gecko-2,
  depending on this new version, and the according shlibs, and we drop
  gecko-1.
- epiphany (and friends) would still depend on gecko-1, so, until it is
  rebuilt, it is not broken either.
- rebuilding epiphany would adjust the dependency on gecko-2 instead of
  gecko-1, without need of adjusting dependencies by hand.

And for the awful case:
- libxul upgrades to version 4, breaking ABI, but we don't notice it, so
  we upload one the provides a gecko-2 depending on it.
- epiphany and friends break.
- we upload a new libxul, providing a gecko-2 package with a dependency
  on older working versions of libxul, and gecko-3 depending on the
  current one.
- now epiphany and friends work correctly again, and we can also rebuild
  them to use the new ABI, and depend on gecko-3.

Basically, we get almost the same as with "normal" libraries, except
that we never change the soname, so that whenever upstream actually uses
them, we don't have to change them.

It is kinda braindamaged, I must say, but it's the cleanest way i see to
handle the situation. I first wanted to do the same without the soname,
but the shlibs mechanism can't work without it...

Or I could just make the sonames correct. I can't quite make my mind.

Any comments ?

Mike