mozilla dependencies and versioned conflicts

Loïc Minier lool+debian@via.ecp.fr
Sun, 22 May 2005 21:02:21 +0200


        Hi,

On Sun, May 22, 2005, 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 kazeh=
akase
> and enigmail update their conflicts: after the fact?

 Mozilla upstream doesn't seem to pay attention to backward
 compatibility for third-party software.  In the case of Galeon,
 upstream is doing an incredibly huge and good work at tracking Mozilla
 trunk and various releases of the Mozilla or Firefox tarballs, and then
 introduce more and more configure tests to deal with the situation.
 The result is something like this:
    <http://patches.theflowerdays.com/tinderbox/>

 Of course, this means Galeon is built for one Mozilla release, and the
 runtime package can't be used for other versions.

 My personal opinion is that this implies we're dealing with completely
 different Galeon and Mozilla binaries in each case; hence I think we
 should live with completely versionned Mozilla packages (that is
 directories, binaries, and packages are named after the current
 release such as mozilla-1.7.5) and third party software are rebuilt
 when their upstream is ready to do so.  (But I don't want versionned
 Galeon/Epiphany/whatever: there would be one single Galeon, that would
 need to be rebuilt when it's ready to be rebuilt against a fresher
 Mozilla, and when it's useful to do so, such as for security releases.)
   Of course my proposal is really a pain to achieve right now, and it
 might be difficult to introduces fixes security-wise, but I think it
 reflects the current issues with the Mozilla releases:
 - they are incompatible, so we need to handle the transitions period
   nicely (instead of the current rush of rebuilds when a new mozilla is
   uploaded and no one will tell you when)
 - software needs to be adapted each time because things are borken, and
   different upstreams might need more or less time to do so.

 So my proposal is particularly awful package-wise and security-wise,
 I'd like to hear about the opinion of other readers on this topic.  May
 be it only counts if we can stabilize things for each release, but the
 transition periods we will suffer from aren't so dramatic as I paint
 them?

   Bye,

[ I'm subscribed to pkg-mozilla-maintainers, and only that in the
  current recipients. ]
-- 
Loïc Minier <lool@dooz.org>
"Neutral President: I have no strong feelings one way or the other."