[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: sense of packaging firefox' addons?

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]