[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