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@xxxxxxxxx> 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
---- ----
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
