Bug#154950: Thoughts on GNOME 2 transition
[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
Reply to: