Let me CC this discussion over to
[EMAIL PROTECTED], who can immediately
point to where I am wrong.
On Fri, 29 Dec 2006, Alexander Sack wrote:
> All extension files belong in the extension subdirectory (for
> icedove/iceweasel).
Please correct me if I am wrong - since the extension is often used by
more than a single ice* application, common practice is to store
it under /usr/share/mozilla-extensions and then relink under the
extension directory of supported applications (/usr/lib/ice*/extensions,
which technically speaking should also be under /usr/share/ice* since
some extensions maintainers might install directly there without symlink
as you said).
As a summary:
Action 1: for ice{weasel,dove},firefox,thunderbird we need just
a symlink in the appropriate directory.
> OTOH, iceape does not yet use the new extension manager and in
> consequence might need to place files in $MOZ_HOME/defaults/pref/ or
> $MOZ_HOME/chrome/. But this has already been done, so all is fine.
Action 2: for icedove,mozilla chrome (optionally pref, so it adds to
action 3) needs to be symlinked appropriately. (also postinst/rm calls
to update*chrome)
Another concern is preferences files which are to be stored under
/etc/mozilla-extensions and symlinked where application expects them
(usually within the extension hierarchy).
Action 3: moving actual preferences file under /etc/mozilla-extensions
and create appropriate link it its original location
So, may be the question is really either all those 3 actions
should be done in some uniform/(semi)automatic way (if that was the case
I barely had to do anything during firefox->iceweasel transition) out of
provided .xpi (or a file hierarchy) which contains install.rdf which has
information on the list of supported applications and some other
information which might be used during installation, or be done manually
by package maintainers as it is done now.
It feels kinda silly that while ice* applications install any extension
automatically without any problem, the maintainer needs to toss
symlinks and files manually while composing the package, although it
seems that such actions might be easily automated, thus uniform across
all the packages.
> What you place in /usr/lib hierarchy and what in /usr/share then lies
> completely in the hand of extension package maintainer and the
> question whether icedove will relink its pref dir should not be
> relvant imo.
The question is not in relinking of preferences -- it is in moving
architecture independent parts under /usr/share to comply with a
policy, and symlinking it under /usr/lib as a quick hack to make icedove
application happy. ice{weasel,ape} already went through such transition.
icedove - did not.
> Ahh, please take a look at:
> /usr/lib/[icedove|thunderbird]/defaults/pref/imagezoom-defaults.js
> and
> /usr/lib/[iceweasel|firefox]/defaults/pref/imagezoom-defaults.js
> those should not be needed in your package afaics. Please remove them
> if possible.
Thanks Alexander, indeed they are useless there and were removed in the
last uploaded version which closed the bug in question.
Also another issue I wanted to raise: there is no agreement on how
to store original source of the extensions:
pure .xpi wrapped in a tarball (easiest and most sensible way since it
allows authenticity testing, but not good if .xpi-shipped .js scripts
have removed indentation to reduce the final size of the downloaded
.xpi, which is the case with ITPed foxyproxy),
extracted xpi in a tarball (broken authenticity for no reason... not
good),
fetched from VC original source (which I did for imagezoom actually)
Which one would you vote for?
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
