Martin Stransky wrote:
Braden McDaniel wrote:
> On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote:
>
> [snip]
>
>> If you're a package maintainer and your package already uses xulrunner,
>> please rebuild it against the new rawhide version. Xulrunner directory
>> has been changed and many gecko packages (if not all) are linked with
>> --rpath linker directive. As long as rpath is used you have to rebuild
>> gecko-libs based packages after each xulrunner change so please consider
>> to remove it. Gecko libraries are registered system wide by
>> /etc/ld.so.conf.d and rpath should not be necessary in rawhide.
>
> But isn't it the case that the libraries in question do not have
> soversions?
>
> If the rpath is eliminated, how do we know when things really *do* need
> to break?
gecko-libs 1.9 exports only frozen interfaces so ideally we don't need
to rebuild any package unless we move to a completely new gecko (firefox
4 ;-))
I don't find that rationale particularly confidence-inspiring. (Since
when did software development proceed "ideally"? ;-)
Are we sure there are no external symbols accessible from public headers
that aren't considered "frozen"? Or are we just sure that blessed
interfaces are frozen?
I don't like the idea of playing without a net here. soversions are how
we track backward compatibility; software that doesn't follow
conventions *should* be handled with the kind of caution that is
reflected in (for example) an rpath. It's a pain in the ass because it
breaks a lot. But it breaks *predictably*. I'm sure I'm as unhappy with
the rebuilds as anyone; but I *like* determinism *a lot*.
Do we have any statements of intent from upstream regarding these
issues? A commitment to change library names when frozen interfaces
change, perhaps?
--
Braden McDaniel e-mail: <braden(a)endoframe.com>
<
http://endoframe.com> Jabber: <braden(a)jabber.org>