[Pkg-mozext-maintainers] XUL Extensions policy directory question

[Alexander Sack]

On Mon, Nov 16, 2009 at 07:50:36AM +0100, Mike Hommey wrote:
> On Mon, Nov 16, 2009 at 12:56:14AM +0100, Benjamin Drung wrote:
> > Am Samstag, den 14.11.2009, 12:38 +0100 schrieb Mike Hommey:
> > > On Sat, Nov 14, 2009 at 12:14:28PM +0100, Benjamin Drung wrote:
> > > > Hi,
> > > > 
> > > > why should the directory /usr/share/mozilla/extensions/common/$foo be
> > > > used for extension $foo? Is there something special about this
> > > > directory? Would it be possible to use /usr/share/$foo instead?
> > > 
> > > Actually, this shouldn't be /usr/share/mozilla/extensions/common/$foo,
> > > but /usr/share/mozilla/extensions/common/${foo:id} where ${foo:id} is
> > > the em:id you can find in then extension install.rdf.
> > > 
> > > The reason why this was put there is that when
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=448260 is implemented,
> > > we will be able to have a canonical location, and no symlinks.
> > 
> > Currently mozilla-devscript does the symlinking for me. It puts the
> > files for extension $foo into /usr/share/$foo and all symlinks can point
> > there.
> > 
> > I think the policy should not force to put the extension content
> > into /usr/share/mozilla/extensions/common/${foo:id} or the existing of
> > this directory.
> 
> Yes, it very much should, because it is the canonical place where
> extensions will live in the future, without any other links.

One concern raised by mozilla on a canonical location for _all_
extensions that only work for some targetapplications - and why we
probably do not want to put everything in common - is that startup
performance will get a hit for nothing if an app has to parse extensions
that are not going to work anyway.

So, common (or toolkit at mozilla.org) really should only get those that
have a targetApplication = toolkit at mozilla.org; all other extensions
should be linked to the appropriate targetapplication directories - like
currently implemented by mozilla-devscripts. Also, since we now have
an automated way to create the proper links, there is not much
maintenance overhead for that approach either, so I don't see why we
would prefer to put everything just in common.

 - Alexander