On Thursday 09 November 2006 10:58, Loïc Minier wrote:
> On Thu, Nov 09, 2006, cobaco (aka Bart Cornelis) wrote:
> > > * I heard a hint from Kevin Krammer who suggested putting a .sh
> > > script in /usr/env to let startkde source it, it could change
> > > KDEDIRS which is a list of directories to search for various
> > > things, in particular configs; I thought about this, but I'm not
> > > sure it can be cleanly implemented, in particular it should work
> > > with locally modified environments, or other scripts setting
> > > KDEDIRS;
> >
> > the above essentially describes re-implementing desktop-profiles
> > as it applies to kde-specific settings
>
> Not really, I agree that desktop-profiles relies on KDEDIRS as well,
> but desktop-profiles is intrusive and too generic for the problem of
> setting the "simple" default.
why do you find it to intrusive?
for KDE all it does is set up KDEDIRS to include the wanted configuration
sets. As you say above you _need_ to do that, and desktop-profiles by
itself doesn not add any configuration. Idem for the other frameworks using
environment variables (i.e. everything but gconf).
As for being generic that's 'A Good Thing' as:
Ultimately it's the local admin that should (be able to) decide what
configuration sets get activated when.
In the presence of multiple agents providing configuration sets that reuires
a central, generic way of controlling them.
Where 'controlling them' means 'controlling of certain specific environment
variables' for all DE's but gnome, and in the case of gnome as a whole (as
opposed to single apps using gconf) you still need to control the
freedesktop variables in addition to the gconf sources.
In the absence of a central generic mechanism you end up with multiple
specific hacks all messing with the same variables, which means the local
admin needs to:
1) identify all agents providing configuration sets
2) figure out the necessary environment variables and the specific semantics
for each variable
3) for each agent figure out how it sets up those variables
4) figure out in which order the various agents variable set mechanisms are
executed
5) given 3 and 4 figure out what the result is and then add in your own hack
to adapt it to what you want
NOTE: agents definining configuration sets would be upstream, the user,
debian proper, various CDD's, the local admin, and (in bigger
organizations) maybe some central ICT-department.
-> at a minimum you'd have 2 sets: upstream and user
-> by default you'd have 3: upstream, debian proper (through
desktop-base), and the user
NOTE: we'll already have desktop-base and debian-edu-config packages
providing configuration sets' (and other CDD's are sure to follow),
so the existence of multiple such agents inside debian is a reality
that needs to be handled.
> My biggest concern goes to the
> per-startkde run configurability instead of a simple per-package
> installation configurability;
(? not sure If I'm getting your point here)
starkde is per-run just like desktop-profiles. And for all non-gnome
desktops (and for gnome where it uses freedesktop specs) where talking
about setting up an environment variable which, by definition[1], is a
dynamic per-run setting.
If you're concern is that you don't want to have 100 packages all adding
their own configuration set then:
I agree that this isn't desirable BUT that's a different discussion
that's completly orthogonal to mechanism used to activate the
configuration sets that are present.
[1] http://en.wikipedia.org/wiki/Environment_variable
> it is of course possible to use
> desktop-profiles to solve this problem, but as I explained, I don't
> want to hook a piece such as desktop-profiles in 1) the default install
if several debian-packages (and desktop-base will make this fact if it
isn't already) are going to add configuration sets it should be done in a
standard central way. As it stands that means desktop-profiles.
-> if desktop-profiles has problems then let's get them out in the open
so they can be adressed
> 2) the list of things launched on every login, even over SSH.
The desktop-profiles script is only run on 'ssh -X' logins, not all ssh
logins, and this is a necessity for any such mechanism (IMO).
After all when starting a graphical app, you need it's configuration
-> you need to make sure the normal configuration sets are loaded when
starting the app
-> which means you need to activate the configuration sets of the various
graphical/desktop frameworks on ssh -X login
NOTE: that's not an academic concern, I added that after getting a bug
repport due to a user running into kmail missing the part of it's
configuration that was preconfigured by debian-edu-config, when
logging in remotely
> > NOTE: depending on exactly what the settings are set in the added
> > config set (not applicable for just setting background, splash) setting
> > KDEDIRS in startkde it isn't sufficient (as kde apps can be started
> > outside a kde-session)
>
> The current goal is to set things such as desktop-background and splash
> image, I think this is always in a startkde use case.
as explained above I think it's an extremely bad idea for each entitiy
providing a configuration set to mess with the environment variables in
it's own way. Hence a generic solution is a must, which makes adding
specific desktop-base KDEDIRS adapting code to startkde a poor solution
IMHO.
--
Cheers, cobaco (aka Bart Cornelis)
Attachment:
pgpK1z1mO0pNB.pgp
Description: PGP signature