Le 25/10/2017 à 13:22, Jason DeRose a écrit :
The problem you describe is a real issue. The flip problem is also an
issue, where the user intends to install a newer version. This is an
issue in distros where many extensions are shipping out of the box,
and the package manager competes with e.g.o. This is also an issue
where the user installs a development version of an extension and the
Update notifier thinks the e.g.o is newer and continually requests
that the user update.
However, giving system extensions favor of a user's local extensions
seems counter-intuitive and blocking the user from updating extensions
on his own system seems potentially maddening.
The issue of letting users upgrading is the proposal of auto-updating.
Nothing will tell that a new release of distribution X will have a newer
GNOME Shell, and so, version compatibility check (which is currently
disabled in most places) won't prevent people to ugprade to a new
*unsupported* version of the extension, which didn't go to the same QA
rules than a traditional Stable Release Update.
Remember that I'm not proposing to favor system extensions for all
extensions, due to the issue you are describing (stalled or old
versions). I'm only suggesting this for system extension enabled from
the current mode (which are already unconditionnally enabled).
In the Ubuntu case for instance, we offer another session with no
extensions enabled by default via a vanilla GNOME Shell look and
behavior. On this one, people would be able to use the new, user's local
version of those extensions.
However, you can consider extensions enabled as part of a mode as being
really part of the Shell, which means, the default desired behavior
which has to be QAed, controlled and such.
Making sense?
Didier
_______________________________________________
gnome-shell-list mailing list
gnome-shell-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list
