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

[Alexander Sack]

On Wed, Nov 25, 2009 at 02:14:28PM +0000, Alan Woodland wrote:
> 2009/11/25 Mike Hommey <mh at glandium.org>:
> > On Wed, Nov 25, 2009 at 01:25:57PM +0100, Alexander Sack wrote:
> >> On Wed, Nov 25, 2009 at 01:03:05PM +0100, Mike Hommey wrote:
> >> > On Wed, Nov 25, 2009 at 12:58:16PM +0100, Alexander Sack wrote:
> >> > > 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.
> >> >
> >> > The startup performance hit should only apply after an extension has been
> >> > installed. Not in other cases.
> >>
> >> Right. still there is no real win from putting it into common ... imo
> >> not something we should put into policy (packages can do that if they
> >> want, but I wouldnt like to make a best practice out of it).
> >
> > The advantage is that once the common directory is supported upstream,
> > there would be no need to modify mozilla-devscripts and rebuild *all* the
> > extensions packages to support any new application id.
> 
> That could always be handled in postinst with the current
> mozilla-devscripts anyway. Better yet couldn't we use the triggers
> mechanism to manage this without having to rebuild all the extensions?

Hmm ... i thought that mozilla-devscripts create links for _all_
targetapplications anyway, so if a new targetapplication gets added it
happens through a new upload/rebuild anyway. Only thing it doesn't do
right for not-yet-known applications is figuring the right depends,
but i think that is acceptable.

Benjamin, can you confirm that md creates those links even for unknown
target applications found?

 - Alexander