On Sun, Jul 21, 2002 at 01:16:28PM -0700, Thomas Bushnell, BSG scribbled: > Marek Habersack <grendel@debian.org> writes: > > > This is not a problem at all, Thomas. Fortunately, the problem with package > > naming applies (mostly) to the, so-called, "core" packages - like the panel, > > nautilus etc. It does not exist as far as the libraries are concerned - > > thus, if a GNOME1 package is not a "core" one it can safely and easily > > co-exist with the GNOME2 environment just by having the GNOME1 libraries > > around. > > Is this true for the instant case, which involves > > 1) having multiple configuration settings for the same variables, and It is possible since the older, GNOME1, packages in vast majority don't use gconf and they keep their settings in the ~/.gnome vs ~/.gnome2 for the newer packages. > 2) the failure of the package to preserve user changes > ? I would consider it a bug of the given package. The GNOME environment, as such, provides means for storing the configuration and it should only take care of its core components' configuration settings. > The Debian policy guide says that you must preserve customizations. True, but I have one remark - see below. > It's not an option, and Christian's handling of gnome packages gives > NO attention to this requirement. I've *never* seen him *ever* do Also true, but (at least at this moment) it is due to the fact that upstream doesn't provide any means of migrating. It would be possible to implement it in our own way but since it is expected to be addressed upstream, it would be a waste of time and effort to implement it in Debian and then switching to using whatever the upstream implements. > *anything* to preserve customizations. If the new package happens to I agree here, but see my above note. I consider this state of things pretty much justified for now (especially that a large part of the GNOME2 packages is still in experimental, which should be enough of a warning for people daring to use the packages). > continue to work, great; if not, then he just says "the world is new, > tough luck". It's PATHETIC and it NEEDS TO CHANGE. I agree here, at least as far the need for changes is concerned ;) > > At the *very least* he needs to leave the bug reports open (dammit) > until the bugs are FIXED. Agreed on that one in 100%. Closing somebody's eyes and shouting "the problem doesn't exist because I cannot see it" is not a good option. But that issue is Christian's call, not ours. > > As far as the "core" packages are concerned the only problem is > > migration - preserving the user configuration. As far as I know, this issue > > is going to be addressed by the upstream somewhere after .2 minor > > release. > > Nope, it's now permanently broken. Adding this later does not help True. I didn't say it is ok _now_, I stated that it will be addressed in the near future. > those who have already upgraded, which, according to Joe Drew was the > goal--encouraging people to use the newer program to test it. I have upgraded and I didn't have much work in getting my old configuration back :). Granted, it wasn't automatic, but still - not that painful. > The result of the test is that it's missing configuration upgrades. I do hope it will change in the future. > And when I report that bug, Christian *closes* the report, with no > real comment or explanation. This is unacceptable, I agree. > > > Replacing the "core" packages (which are what actually forms the > > "environment") is, IMHO, quite OK as long as they preserve (at least to some > > degree) the user's configuration, which should happen sometime in the near > > future. > > "preserve to some degree" is not what the policy manual says, and > preserve is something that has to happen *when the new packages are > replaced*, not at some point later. Once it's later, it's *too late* > to preserve the customizations. Note one thing (this is the remark I was referring to above) - it is not always possible to preserve some settings merely because they might cease to exist in the newer packages or they might've changed their meaning and the effect on the package they have. That's what migration is all about - adapting the new version of the package so that its configuration resembles the older one as closely as possible, considering the substantial changes made to the package in question (I realize perfectly that the current GNOME2 packages do _nothing_ in that respect, but that's a different matter here). As it is evidenced by quite a few packages in the GNOME2 distribution, many options are gone or changed their meanings - I imagine that it is quite a demanding task to create a migration path for those packages. Having said that, I think it's perfectly OK for such packages to be present in the unstable distribution but not at all OK for them to be available through testing. Maybe the GNOME2 packages should be kept in unstable only for that reason? regards, marek
Attachment:
pgpOtDbNLCKHh.pgp
Description: PGP signature