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

Re: RFC: some new deb package flag: "upgrade-conflicts"



Erich,

> Debian wants to provide a clean upgrade path for all packages.
> But sometimes this is not possible (because it would require modifying
> the users' home directories and such stuff)
> Maybe it could be useful to have some kind of "upgrade-conflict" of
> packages - these packages shouldn't be upgraded automatically, and
> should probably be given the possibility for displaying a debconf note.

Debian packages are expected to be upgradeable with skipping one
release. After that, behaviour is officially undefined (but leaving the
upgrade path in the postinst doesn't harm in most cases). So what you're
proposing is in fact there, but not formalized for the package manager.

There are a few approaches to problems like these:

 - Ask the administrator in the config script whether she allows
   upgrading of users' config files, then do it in the postinst.
 - Provide a wrapper that asks the user whether she wants to upgrade her
   config files
 - Hack the source so that old-style configs can be read in (issuing a
   warning)
 - Hack the source so that an old-style config is ignored (issuing a
   warning)

Number one is most admin friendly, yet if the package maintainer screws
up, she has lots of users screaming at her. Number two obviously works
only for interactive programs and sometimes degrades performance, but is
the best approach IMO. For the mail filter, the best idea IMO would be a
mixture of 3 and 4 (ignore everything that can be rebuilt, try to
understand the rest and issue a warning [mail the user using the
filter]).

> It could have been useful for galeon1, too - during it's early stages
> (like version 0.1x) upgrades often required that you remove your .galeon
> directory. This was "solved" by showing a debconf note when an upgrade
> from such a version was detected;

Think computer science lab installations. The admin has the choice of
either deleting users' personalized config files (=> users screaming) or
having their browsers fail (=> users yelling).

   Simon

-- 
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD  ADC6 18A0 CC8D 5706 A4B4

Attachment: pgpA80uZOSjFT.pgp
Description: PGP signature


Reply to: