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

Re: Christian Marillat, once again

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
2) the failure of the package to preserve user changes

The Debian policy guide says that you must preserve customizations.
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
*anything* to preserve customizations.  If the new package happens to
continue to work, great; if not, then he just says "the world is new,
tough luck".  It's PATHETIC and it NEEDS TO CHANGE.

At the *very least* he needs to leave the bug reports open (dammit)
until the bugs are FIXED.

> 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
those who have already upgraded, which, according to Joe Drew was the
goal--encouraging people to use the newer program to test it.

The result of the test is that it's missing configuration upgrades.
And when I report that bug, Christian *closes* the report, with no
real comment or explanation.

> 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.


To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: