[Fedora-spins] Board SWG questions for Spins Owners

[Bill Nottingham]

Christoph Wickert (christoph.wickert at googlemail.com) said: 
> > > > The first is a policy issue that could be redressed. The second is
> > > > unlikely to change (and would imply you'd be signing up to write your
> > > > own if you didn't want to use anaconda/firstboot, which I can't imagine
> > > > is what you want), and the third probably requires patch submissions.
> > > > 
> > > > (Note: due to the requirements for a window manager at installation
> > > > time, anaconda may very well require metacity in the near future.)
> > > 
> > > Why not a virtual provide and let the spin maintainers and users decide?
> > > In F12 we changed anaconda to use any display manager that has a virtual
> > > provides for "service(graphical-login)" instead of hardcoding a list of
> > > display managers. We should do the same for window manager.
> > 
> > anaconda, firstboot, and whatever would need a mechanism to start
> > random-window-manager of the day and adjust the configuration as needed.
> > If that's important to people, they should submit patches.
> 
> It is not random but defined by the user or maintainer. All the spins
> except the Desktop Spin already (have to) configure 
> /etc/sysconfig/desktop.

Getting arbitrary things into the anaconda image isn't trivial - it involves
explicitly listing packages and files to use. firstboot's a little better,
as it's actually working on an installed system. As I said, if you or others have
interest in making this possible, the way to start is with patches or patch proposals.
Get all the WMs that people might want for this providing something that can
automatically determine the command to run. Make sure that they all do the
right thing without needing random arguments passed to them. Then work
from there with patches to apps.

> > > > What prevents you doing in in Fedora? Have you submitted a package
> > > > review, or an example spec?
> > > 
> > > I cannot submit a package review because the files included in the
> > > package conflict with the current packages.
> > 
> > How so? Just package up some settings in the /etc/gconf.xml.system
> > directory.
> 
> First of all I'm not interested in GNOME any longer, so there is no
> reason for me to submit such a package. I just named it as an example
> for smarter packaging.
> 
> Second: If the files do not confligt, how to prevent gnome-panel from
> reading other /etc/gconf/schemas/panel-* files? How to resolve
> conflicting settings?

It's a heirarchy, it's how gconf works. But, really, when your argument goes:

S: This is a problem!

A: OK, why not work for it?

S: I can't, there are conflicts!

A: No, here's how you can do it.

S: But I'm not interested in doing that anyway.

... ugh. If you've got technical concerns you're willing to solve, I and others
can try and point out the best way to solve them. If you're just tossing out
complaints with no intention of working towards a solution...

Bill