Christoph Wickert (christoph.wickert@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