[Desktop_architects] Deskop configuration management

[Bastian, Waldo]

>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. 

That's the cause that needs fixing then. The rest is fixing of symptoms.

>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).

How is that supposed to work if you have multiple desktops on the same
system, as per your suggestion below?

>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. 

The point is that it is something a distribution has to set to match its
overall system policy. The problem is that distributions don't seem to
understand how to do that properly. Whether it means setting a env. var.
or putting a file in /etc seems to make little difference to that
problem.

>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.

XDG_DATA_DIRS allows you to hack up that kind of functionality in your
startup sequence, I consider that a pro. Deferring that to /etc/xdgrc
requires that you need to pull in all the semantics into some kind of
spec and wait for all implementations to catch up with it. KDE can get
away with putting such policy in /etc/kderc because there is a single
implementation interpreting /etc/kderc, with /etc/xdgrc that will not be
the case.

>> 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.

I think it's primarily an education issue. But I might change my mind if
you can point me to bugreports that indicate a more fundamental problem.

Cheers,
Waldo