Planned changes to iceweasel/iceape vs. freeze

[Adam D. Barratt]

Hi,

Apologies for taking a little while to get back to you about this.

On Mon, 2010-08-09 at 16:06 +0200, Mike Hommey wrote: 
> 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 ;) )

[re-ordering your list of changes a little]

IMO, these sound ok:

> - 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.
[...] 
> 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.
> - 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/
> - 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.

My only concern with the removal is that people may be relying on it
locally, although no packages in the archive depend on it.  Admittedly
that's not a particularly overriding argument against shipping
unmaintained code in stable.

These are presumably "nice to have"s, but sound low impact:

> - 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".
> - 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.
> - Improve the xpcom standalone glue so that it loads the most
> appropriate version instead of the first one it finds that matches the
>   criterias.

and the remainder:

> - Improve dh_xulrunner to also gather plugin information to, in the long
>   term, help mimic Ubuntu's Xb-Npp-* control fields.

Forgive my ignorance here, but what are the fields in question used for?

> - Add an option to dh_xulrunner to add the appropriate xulrunner package to
>   something other than shlibs:Depends.

Are there specific use cases for this right now?

> - 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

This would imply improving rather than removing, afaics.  (As removing
it would presumably still leave the potential for things to go horribly
wrong over a major version update?)

Finally, how large a change to the package do the following items imply?

> - 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)

Regards,

Adam