[Desktop_architects] Deskop configuration management

Aaron J. Seigo aseigo at kde.org
Tue Dec 27 12:03:45 PST 2005


On Tuesday 27 December 2005 11:45, you wrote:
> > - XDG_DATA_DIRS. this has already caused problems for us with the menu
> >spec in that it can't be changed within a session,
>
> Why would you want that?

because they are set wrong. so the user has to set up the env var then log 
out, log back in ... innevitably they try and just set it in a terminal 
window; or they'll set it, rebuild sycoca (and now things are good) and then 
get annoyed when it "randomly" breaks again (e.g. when a new .desktop file 
appears or the cache is some other way invalidated).  it's very confusing for 
normal, average users (where "normal, average" is meant to refer to our 
current user base demographics, not even the larger world of computer users).

no, it should've been a simple configuration item set in a file in a system 
wide config location. that way new desktop installations could just install 
an updated file (or a new file altogether). 

look at the layout of /etc/profile.d; now there's a good solution. we already 
look at hardcoded locations for certain vars, so it's not like that's not 
doable.

> >can't be changed by
> >installing a new desktop (think of multiple desktops on the same
>
> system)
>
> Each desktop startup sequence can adjust it accordingly, if so desired.

and yet they don't. i chalk this up to it being an ephemeral "environment 
variable" rather than a well defined file-backed value. it also means we have 
one mechanism for overriding values for group policy (cascading configuration 
flies) and another for overriding these values for XDG_DATA_DIRS (different 
env profiles based on group membership, sth you generally have to hack up 
yourself just like the bad old days before kiosk's profile dirs 
in /etc/kderc.

it probably ought to become /etc/xdgrc in the future and handle these things.

> >and if often just plain set incorrectly (if at all) by packagers.
>
> Possibly, yes.

often. with 3.5 we've seen this problem with both Red Hat and Kubuntu.

> >honestly,
> >using XDG_DATA_DIRS was a huge mistake. i have the numerous (invalid)
>
> bug
>
> >reports to back that statement up. let's not replicate that mistake to
> >other specs.
>
> I think there is some value in consistency here. By using XDG_DATA_DIRS
> consistently across specs, the problems associated with it only need to
> be fixed once.

one can fix a leaky dinghy all they like, doesn't change the fact that it may 
well be time to get a new one. 

given that this creates problems for real world people over and over, and not 
just neophytes but even people doing deployments and people designing 
operating systems, it is worthwhile to reconsider the whole approach.

> Note that a lot of the problems seen with XDG_DATA_DIRS are actuallly
> problems of the menu specification. See

no. these are problems with XDG_DATA_DIRS. i've been dealing with them with 
increasing frequency since KDE 3.4 on bugs.kde.org and irc both. very 
frustrating.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/desktop_architects/attachments/20051227/93165430/attachment-0001.pgp


More information about the Desktop_architects mailing list