mozilla dependencies and versioned conflicts

Alexander Sack asac@jwsdot.com
Sun, 22 May 2005 15:23:52 +0200


Steve Langasek wrote:
> 
> The question is, how can we be proactive about identifying the classes of
> changes that do or don't break these packages, so that mozilla can be
> checked for compatibility at the time of upload instead of having kazehakase
> and enigmail update their conflicts: after the fact?
> 

I suggest to list all indicators we are currently aware of, in order to get a
good list on what needs to be checked before assuming compatibility of a mozilla
patch.

For now, I can see three classes of mozilla dependents:
 + extensions
 + locale packages
 + gecko dependents

Reasons that might break extensions include:
   + changes to XPCOM interfaces (e.g. .idl)
   + changes to XUL overlay anchors (e.g. new/removed/renamed XUL element ids).

For locale packages, breakage is typically a result of changes to the set of
defined dtd entities. So everytime a new dtd entity is introduced we must
consider the diff incompatible and try to figure out a way to not introduce that
change.

For gecko changes, the usual library procedures should apply, right? Maybe
someone else can provide a checklist what is actually needed to keep track on
incompatible gecko changes?

If you are aware of other reasons, please add them to the discussion. The more
complete the list is, the better we can check an upstream patch for potential
package breakage.

Cheers,

-- 
 GPG messages preferred.   |  .''`.  ** Debian GNU/Linux **
 Alexander Sack            | : :' :      The  universal
 asac@jwsdot.com           | `. `'      Operating System
 http://www.asoftsite.org  |   `-    http://www.debian.org/