On 04/27/2011 10:46 AM, Duncan wrote: > Samuli Suominen posted on Tue, 26 Apr 2011 21:56:06 +0300 as excerpted: > >> You have 24 hours to comment on this news item. Sorry to put it so >> bluntly but this is required for major security bug (#364973). >> >> See attachment. >> Title: Upgrade to GLIB 2.28 Author: GNOME Team <[email protected]> >> Content-Type: text/plain Posted: 2011-04-26 Revision: 1 >> News-Item-Format: 1.0 Display-If-Installed: <dev-libs/glib-2.28 >> >> The way of setting default URI handlers has changed since >> dev-libs/glib-2.28 and above. If you used the GConf registry to set them >> before, they will now be ignored. >> >> If you use GNOME, you must upgrade gnome-session and >> gnome-control-center and set your default browser/mail-client again. >> >> If you don't use GNOME, you should ensure that the file >> ~/.local/share/applications/mimeapps.list has the following content: >> >> [Added Associations] >> x-scheme-handler/http=$browser_name.desktop; >> x-scheme-handler/https=$browser_name.desktop; >> x-scheme-handler/mailto=$mailclient_name.desktop; >> >> Replace $browser_name.desktop and $mailclient_name.desktop with the >> appropriate file from /usr/share/applications that can handle >> http/https/mailto URIs. >> >> Please make sure that your browsers and mail clients have been upgraded >> to the latest stable versions before doing all this. > > This is unclear. Should non-gnome users (I'm a kde user) set this to > prepare for the upgrade, or as a workaround until one actually completes > the upgrade?
It's a permanent thing... I think the item is clear on that... "The default way has changed", no where implying this would go away or be temporary, or a workaround The KDE desktop should set those mime's already, if you have selected default browser/mailclient from the desktops GUI apps. If not, file a bug for the KDE people. > The question comes up, because I'm on 2.28.6, which should be above the > threshold for the notice, and I have that file in my home dir, but do NOT > have those entries in it, which the notice appears to imply I should. The news item is targeted for stable users... presumably ~arch users know what they are doing. Hence the Display-If-Installed. > > Second point: To clarify, you're asking presumably admin users to set > this in their homedir config, right? There's absolutely nothing in the > proposed news item (and no link with it as a further detail) explaining > this rather unprecedented tampering with a user's private homedir config, > nor anything explaining what happens if it isn't done. Should an admin by > arbitrary fiat edit the entries for *ALL* users? Just his own? > > If this is intended to be a system level policy edit, why isn't it *AT* > they system level? If there is indeed technical reason to go editing > individual user's homedir configs, then PLEASE make it MUCH CLEARER just > WHICH user configs need to be edited (presumably all of them), and provide > some justification, technical or otherwise, why editing the user config is > the chosen solution. > > Note that as I implied above, a further details link is very likely > appropriate, since news items are normally quite brief, serving in many > cases more as an alert to check the details elsewhere than a full > explanation and instructions. > Addressed the system-wide vs. user defined issue in the new draft (responded to the original post of this thread with it). Has a link now too.
