Re: RFC: some new deb package flag: "upgrade-conflicts"
- To: Simon Richter <firstname.lastname@example.org>
- Cc: email@example.com
- Subject: Re: RFC: some new deb package flag: "upgrade-conflicts"
- From: Erich Schubert <firstname.lastname@example.org>
- Date: Tue, 1 Oct 2002 10:26:18 +0200
- Message-id: <[🔎] 20021001102618.A19815@gandalf.drinsama.de>
- In-reply-to: <20020930233855.GA10976@phobos.fs.tum.de>; from email@example.com on Tue, Oct 01, 2002 at 01:38:55AM +0200
- References: <20020929194250.GA19701@dman.com> <firstname.lastname@example.org> <20020930164631.GE21018@jdj5.mit.edu> <email@example.com> <20020930230003.GC27429@bombadil.xmldesign.de> <20020930233855.GA10976@phobos.fs.tum.de>
> Number one is most admin friendly, yet if the package maintainer screws
Well, i think number 3 is even more admin friendly. But a lot of work
for the maintainer usually.
> 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).
It's not too difficult to add a config-version file and check that in
the wrapper. As galeon has a wrapper anyway i did that while gconf was
broken: write the debian version into .galeon/version and install the
gconf templates into the users .gconf directory.
That way i could then, when gconf was fixed, automatically uninstall
these templates - still if a user wants to re-add them for some reason
they will not be uninstalled a second time.
Computer Science labs might have even bigger problems, where the only
obvious solution is to issue a warning and not automatically upgrade:
What if the systems run different versions - out of the same home
Issuing a warning to the administrator that after an upgrade
configuration files will become incompatible to older versions, and that
he should upgrade all machines at least to a certain version.
Unfortunately that would probably keep a lot of software from
upgrading... - and administrators in such "big" networks should read
changelogs anyway - and test software on a separate system before
deploying it to their users...
Well, i just liked the idea of marking whether a clean upgrade path
exists. Could even stop the Gnome2-not-reading-gnome1-config screaming.