Planned changes to iceweasel/iceape vs. freeze

[Mike Hommey]

Hi,

I don't remember where I got this idea that the freeze was expected to
happen somewhen late this month, but I was taken by surprise by the
freeze happening already. Anyways, the mozilla packages I take care of
are in a releasable shape already, but there are more changes that I was
planning to do some time this month, or at least for next upstream
releases, scheduled for september 7th. I'll list these below, please
tell me for which I can go forward (hopefully, all ;) )

- Iceweasel and xulrunner are currently two separate source packages,
  sharing the exact same tarball. It is the result of the packages
  history, and it would be better if they were merged, for several
  reasons:
  - It is a maintenance burden.
  - I suspect some stable users are not upgrading xulrunner on their
    stable systems, leaving their iceweasel at risk. Having new
    iceweasel packages at the same time would allow to force xulrunner
    upgrade with dependencies. While this can also be done with the
    current split source packages, it adds a lot of work, especially
    when there really is no change in the iceweasel package itself.
    Currently, only xulrunner is updated in stable-security except when
    there are browser-specific changes (which hasn't happened for a
    while).
  - It should allow to run browser-specific tests more easily.
  Obviously, only the source packages would be merged. All the resulting
  binary packages would stay the same.
- Improve dh_xulrunner to also gather plugin information to, in the long
  term, help mimic Ubuntu's Xb-Npp-* control fields.
- Add an option to dh_xulrunner to add the appropriate xulrunner package to
  something other than shlibs:Depends.
- Add a /usr/lib/xulrunner-devel symlink to /usr/lib/xulrunner-devel-
- Add links to nspr-config and nss-config in
  /usr/lib/xulrunner-devel-1.9.1/bin/, and possibly some other missing
  files compared to upstream "sdk".
- Apply fix for https://bugzilla.mozilla.org/show_bug.cgi?id=504766
  (debian bug 591512)
- Apply fix for bug 590040.
- Add local homepages when upgrading and running for the first time,
  instead of the pages on http://mozilla.debian.net/
- Improve or remove the restart popup that shows up when upgrading the
  package. The main problem it is trying to avoid is the impossibility
  to cleanly close iceweasel after an upgrade. I need to test further,
  but there are chances this is really only needed when upgrading
  between major versions. I'm not entirely sure it has a benefit for
  other cases, though apart from one complaint on planet.debian.org, I
  saw no feedback... there are a bunch of known issues with it, like
  with multiple iceweasel windows, or like not activating again when
  the user doesn't want to restart now but the browser is upgraded again
  later.
- Generate the iceweasel branding from upstream unofficial branding. I
  spotted a missing file in the current branding, so this would fix this
  and avoid it happening again in the future.
- Improve the situation with search box icons (those showing up in the
  box on the top right of the UI):
  the main problem is that the icons had to be removed from the source,
  because they are not free. The result is that now, the icons are
  really links to the icons on the original web sites. The problem is
  that the code surrounding this upstream is not adequate for such use,
  and the cache is not persistent enough, and a failure to load the icon
  once results in the icon never been reloaded ever again (except maybe
  after an upgrade)
- Improve the xpcom standalone glue so that it loads the most
  appropriate version instead of the first one it finds that matches the
  criterias.
- Provide a "generic" xulrunner binary, so that one can run
  /usr/bin/xulrunner application.ini instead of /usr/bin/xulrunner-1.x
  application.ini. The most appropriate version would then be used.
- Possibly remove the libmozillainterfaces-java package. It is
  apparently unused, not really maintained upstream (it's even being
  removed from current trunk, in favor of a separate repository if a
  maintainer shows up), and more importantly, not tested.

Please note that most if not all the changes above will be applied
anyways on the 3.6/1.9.2 packages currently in experimental, and
4.0b/2.0b packages in http://mozilla.debian.net/packages.

Other than that, as with previous freeze periods, I'd like new upstream
(minor) releases to be allowed to go through.

Cheers,

Mike