sense of packaging firefox' addons?

[Andrew Farris]

chasd wrote:
> For the single end user that manages his /her own computer, it doesn't 
> matter how the add-on is deployed. In fact, there are advantages to the 
> way Firefox handles it. In an environment that is managed by a 
> "professional" , using the distribution package manager for add-ons has 
> many advantages.
> 
> As an administrator, I would prefer to control what Firefox and 
> Thunderbird add-ons my users have access to, and allow the system-wide 
> management tools to tell me what add-ons are installed and what are the 
> exact versions of those add-ons.

And most users would rather not wait for their administrator to get around to 
their station to deploy a new addon they found out about, which is supposed to 
make them more effective at doing their job rather than waste time trying to get 
the IT guy to handle it.  Most admins don't want to have the excess work of 
building custom packages for those addons just to let the user test the addon.. 
only to find it is inadequate for their needs.  You will not find an adequate 
solution based only on system-wide installation for these addons unless the 
users are simply denied any other option (i.e. not an effective way to deal with 
the desktop user).

> Some add-on versions are locked to a 
> specific Firefox version. An administrator would take that into account 
> when rolling out updates. yum /rpm could bark if an update to Firefox 
> was attempted before an updated add-on was available ( as long as the 
> correct version requires were in the add-on package ).

And if you updated firefox by its own update system it would warn you that the 
update would break your extensions before it let you apply the update.  I'm not 
suggesting we do that, but the fact is that upstream has done that work so it is 
not wasted effort (it already exists).  The extra work is in fact creating 
packages for all these addons (a rapidly changing group of small code bits).

> Code for self-application updates ( and add-on updates ) is IMHO wasted 
> effort since the code and infrastructure already exists in the distro 
> platform ( yum, rpm ). Only in the proprietary OS world do applications 
> need to re-invent the update wheel because the OS update mechanism is 
> closed to most application developers and is only available to the OS 
> vendor for its own applications. Having Firefox update itself and its 
> add-ons is a consequence of its deployment on Windows. It is not 
> necessarily the best way on Linux.

I would agree with that last statement, partially, but the fact that 
self-updates is not necessarily the best option does not mean that system-wide 
updates are the best option either.  There are systems for deploying windows 
updates through IT administrators as well.. but that is inadequate to solve the 
problem of firefox addons (which is the real reason why the self-update system 
exists for them, not because there was no other option in the windows world).

There are many use cases where the system-wide package management is nothing 
more than overhead and in the way of getting the job done.  Creating an RPM spec 
is additional work to be done and takes the time and effort of someone which 
causes more delay in deployment.  It is also a heavy amount of work to package, 
build, and distribute a very rarely used addon for a small group of users.  It 
does not make sense to remove or block the user's ability to install extensions 
through the provided firefox interface, unless that is for very specific 
security reasons within a managed IT infrastructure.

I could see their being an advantage in pushing out a set of system-wide firefox 
extensions to a group of lab machines, but is it really worth the effort it will 
take on an continual basis to keep these small extensions updated?

-- 
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----