[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Christian Marillat, once again

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


Attachment: pgpOtDbNLCKHh.pgp
Description: PGP signature

Reply to: