After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 644463 - Extensions should be whitelisted (not blacklisted)
Extensions should be whitelisted (not blacklisted)
Status: RESOLVED DUPLICATE of bug 651088
Product: gnome-shell
Classification: Core
Component: extensions
2.91.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-03-11 03:08 UTC by John Stowers
Modified: 2011-05-25 21:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description John Stowers 2011-03-11 03:08:21 UTC
I think it is more sensible to have system-wide extensions disabled by default (and require being white-listed) instead of the current behavior where all installed extensions are enabled until explicitly disabled. My reasons for this are

* gnome-shell-extensions builds all extensions by default, the net effect being the default install changes the shell in many ways
* it means that distro packers can create just one package for g-s-e and not many subpackages
* it matches the behavior of gedit, etc where the -plugin package installs many plugins that are disabled by default
* it more correctly meshes with the idea of user extensions (which likely would be enabled by default)

So, is this a good idea?

Would you take a patch that either; requires white-listing system extensions, or requires white-listing all extensions?
Comment 1 Colin Walters 2011-03-11 20:46:32 UTC
White listing system extensions I think is definitely a good idea; it seems likely to me that people deploying system extensions are more likely to only want them for a few users, than to have them for all.  Either way of course it's just a matter of scripting gschema for users.

Not a big fan of white listing all extensions, but if it makes the code a lot cleaner or something we can do it.
Comment 2 Colin Walters 2011-05-25 21:48:04 UTC

*** This bug has been marked as a duplicate of bug 651088 ***