[take 2, I posted this to a perl 5.8 transition moaning bug by mistake, d'oh]
I've just switched over to GNOME 2 from experimental. I wanted to add one or two points here. First, having foo and foo2 is very very ugly, and provides no upgrade path sensibly. If we move packages in sid over to their GNOME 2 versions with the same name, and keep the GNOME 1.4 libs available (without breaking the ABI, see #158165), then we have the time in unstable until sarge to deal with any configuration issues as we see fit. Programs without a gtk2/gnome2 port will continue to work. Second, there are common elements between GNOME 1 and GNOME 2 that make having them co-exist un-desirable. Particularly, the gnome-session and gconf databases are shared or at least backwards compatible. This broke my desktop - the background settings capplet was being loaded at the same time as the new gnome-settings-daemon. Gnome-control-center2 should conflict with gnome-control-center for this reason, or actually just exist as an upgrade to it for the above reason. Thirdly, the configuration that we are talking about is in no way as important as, say, apache or your MTA. It took me in the region of 15 minutes with GNOME 2 to restore my desktop to an approximation of how it was with GNOME 1.4. Some kind of greeter in gnome-session could make a best-faith attempt at reading in the desktop files from GNOME 1.4 and applying the settings to GNOME 2, but a direct mapping is simply not possible because some options have failed to exist. And if we do that, which is arguably the cleanest route, then we can't co-exist GNOME 1.4 and GNOME 2 on a system because we'd then be maintaining two sets of preferences. One or two things would need to be maintained in the GNOME 1.4 config to ensure the apps linked against it still function as expected - the one that comes to mind is the URL handler. That's reasonable, for GNOME 2 to maintain one or two values to ease the transition from GNOME 1.4. What is not reasonable is to expect GNOME 2 to track configuration changes that the user could make if they decide to go back to GNOME 1.4. That's just not practical. And it's ridiculous to even consider making GNOME 1.4 change the GNOME 2 settings in general terms. What I'm trying to say is that it's kindest for our users, and tidier to boot, to aim for GNOME2 in sarge, and have gnome-session pull in any relevant GNOME 1,4 configuration, and have gnome-control-center and gnome-settings-daemon make any changes back to keep GNOME 1.4 apps ticking over. Side points are that a bunch of stuff in unstable already became GNOME 2 without appending/inserting a 2, so reverting those would cause un-necessary configuration loss beyond that the user accepted by installing GNOME 2. Also, renaming packages for any future upgrade is hard without stub packages and metapackages to aid the transition, so what we decide now will hang over us for at least two releases. Do we really want to be dealing with GNOME 1.4 package names long after all the apps have switched? And I imagine soon, development will drop off sharply on GNOME 1.4 except for simple maintainance releases of the libs. Do we want to keep around software that has been deprecated by upstream and take on the burden of maintaining it ourselves? Does that jibe well with the social contract? Just some thoughts... Regards, Rob
