gnome-shell-3.0.x by default loads and runs all extensions that are installed on the machine. The gnome-shell-extensions-3.0.x ebuild currently installs all extensions provided in the tarball (and in fact offers no way to disable or not install individual extensions). This obviously leads to problems because (a) only a tiny minority of crazy people would want to use *all* of these extensions simultaneously; (b) some extensions are known to make gnome-shell outright crash (possibly depends on the user's video drivers). The current behavior is basically equivalent to providing a "firefox-extensions" ebuild that installs a dozen browser extensions, some useful (but only to a few people), some nearly useless, some that make the browser crash - and have no way to control which set of extensions gets installed. Basically, insane. I see two possible solutions to the problem. First, add a USE_EXPAND variable (say, GNOME_SHELL_EXTENSIONS) that controls what extensions get installed. I would have already done this in the overlay, except that adding a new USE_EXPAND apparently requires messing with the base profile and a discussion on the gentoo-dev mailing list (and I am not a gentoo dev). Second, split up the package into gnome-shell-extensions-alternative-status-menu, gnome-shell-extensions-user-theme, etc. This is what Fedora does, but it doesn't feel like the "Gentoo way" of doing things. This *must* be fixed before gnome3 is unmasked in gx86 because one of the extensions (alternative-status-menu) is basically required for certain corporate deployments; see https://bugzilla.gnome.org/show_bug.cgi?id=643457
Created attachment 281619 [details] proposed USE_EXPANDed gnome-shell-extensions-3.0.2.ebuild
Created attachment 281621 [details] proposed USE_EXPANDed gnome-shell-extensions-3.0.2.ebuild Same as above, but without a duplicate gnome-desktop dep
I would prefer the "splitted" way over USE flags if it's not too hard to handle. That way, I wouldn't need to re-compile all extensions if I decide to enable/disable one of them :-/ But it's only my opinion, better wait for more :-)
(In reply to comment #3) > I would prefer the "splitted" way over USE flags if it's not too hard to > handle. That way, I wouldn't need to re-compile all extensions if I decide to > enable/disable one of them :-/ Almost all shell extensions are written purely in javascript and don't need to be compiled :)
Nice to know :D
After thinking about this problem further, I've decided that the best solution would be an eselect module. By default, extensions would be installed in some directory where they wouldn't be loaded automatically (e.g. /usr/share/gnome-shell/extensions.available/), and eselect will symlink the ones that the administrator wants to enable into /usr/share/gnome-shell/extensions. The eselect solution has the following advantages: 1. The administrator will be able to change the list of extensions enabled systemwide without rebuilding gnome-shell-extensions (although there is no compilation step, running configure 20 times is still annoying). 2. It reduces the future maintenance burden on the gnome team, since there will be no need to keep the list of USE flags in sync with the list of provided extensions in all shell-extension packages (and it's inevitable that we will add various third-party hell extension packages). 3. Unlike the USE_EXPAND solution, the eselect solution doesn't require configure script sedding and hackery in the gnome-shell-extensions ebuild. Unless anyone objects, I will implement this in the overlay tomorrow or so.
Fixed in overlay with a gnome-shell-extensions eselect module that works in a somewhat more elegant manner (it manages a gsettings vendor override for the org.gnome.shell disabled-extensions key).
