ABI breakage and package naming

Planète Béranger has raised the ABI issue surrounding Fedora and RHEL’s recent upgrade to Firefox 3. In short, RHEL 5.2 ships with Firefox updated to the new xulrunner-based Firefox 3, but its Eclipse and libswt3-gtk2 is still at 3.2, which depends on the old gtkmozembed interface.

This seems like a good argument in favour of adopting Debian-style package naming, when it comes to libraries: append the ABI version to the (sub)package name containing libraries that are linked to from other packages. So the old Firefox 1.5 would have a libgtkmozembed18 subpackage, that can be shipped with RHEL 5.2 without shipping the rest of Firefox 1.5 (technically speaking, the ABI version is 1.8.x.y, as prior to XULRunner 1.9 the ABI is ever-changing, but packages already handle this by depending on the specific version and release number anyway)

This is already done from time to time in the RHEL/Fedora world, in the form of compatibility packages, but making it the default would avoid this kind of breakage, where a package /has/ to be updated (due to upstream EOL) but parts of it are needed downstream.

3 responses to “ABI breakage and package naming

  1. NO, I am NOT Daniel Béranger. I am not who you think I am. Please do your homework.

    Compatibility packages CAN be released and the dependent applications (Eclipse) CAN be rebuilt against them NO MATTER what package naming scheme you adopt. It’s just a matter of willing to do it, because there is always more than one solution.

    BTW, Firefox 2 is supported till end-2008, so the upgrade to Firefox3 BETA5 was NOT mandatory for RHEL 5.2.

    OTOH, Red Hat hat a LOT of time to figure out a solution for the package naming and/or compatibility packages.

  2. My mistake (must have confused you with someone else.. sorry!). Incidentally, this explains the Romanian posts on your blog.

    Upgrading to Firefox 3 beta 5 is not necessary, I agree. I suppose the maintainer want to avoid having to deal with three versions (Firefox 1.5 for RHEL 4, 2.0 for RHEL 5 and 3 for Fedora).

    The problem with the current naming scheme is that it just *invites* compatibility problems to recur from time to time. Having libraries be parallel-installable didn’t use to be much of a problem in the past, but with the divergence between RHEL and Fedora release cycles, this is becoming more of an issue.