Firefox 3 Beta 2 in Rawhide

[Braden McDaniel]

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 at endoframe.com>
<http://endoframe.com>               Jabber: <braden at jabber.org>