Havoc Pennington wrote: > Hi, > > Brian Nitz wrote: > >> One problem I hear about from time to time is when someone is using the >> same home directory for several sessions on different machines which may >> be running different versions of GNOME. >> >> e.g. Logged into my NFS home directory on a laptop running Gnome 2.10 in >> ubuntu. >> Simultaneously logged into the same home directory on Sun Ray running >> GNOME 2.20 on Solaris Nevada. (and/or Gnome 2.6 on Solaris 10!) >> >> I know we can't fix past problems (easily), but if we consider the >> possibility of this sort of use, we might make things better down the road. >> >> > > Indeed. There are some past discussions of this. The challenge is that > for all the on-disk stuff people have to maintain not only backward but > also "forward" compatibility; you can't do things like add a possible > value of a gconf key that will break older versions of the program. > I understand. Until then I can only recommend the hack to put different versions of GNOME config files in different subdirectories and use a script or manually port config file values between releases. > Unfortunately it's very hard to be sure nobody introduces any bugs of > this type, in any application, between any of the possible combinations > of GNOME versions... it's good to remind people of the issue and try to > minimize the bugs, but without a pretty extensive effort to QA the > behavior of GNOME releases in this context, I'm doubtful it will > reliably work to mix arbitrary GNOME versions with a shared homedir, > sadly. It's very easy to break this accidentally and in each release > there are many changes people make that are likely to break it. > Yes, it is hard work to QA every combination of (N keys + R releases)! This is why when I receive complaints of such behaviour in unstable releases, I can only recommend to log the bug against failure of key portability in a specific combination of stable releases. I don't want to add anything heavyweight to gconf, but I wonder if associating stability values with gconf keys and key subdirs would help manage future portability and allow as much configuration inheritance as possible without breaking everything?
> Havoc > > _______________________________________________ > desktop-devel-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
