On Fri, May 04, 2001 at 12:34:04PM +0200, Jens Schmalzing wrote:
> Hi,
>
> Ethan Benson writes:
>
> > otherwise when the package is later upgraded the config file is
> > again blown away.
>
> It's a feature. If you say `yes' to automatic configuration, you are
> handing the whole thing to debconf once and for all. Well, at least
> until you dpkg-reconfigure the package and say `no'.
sorry but this doesn't fly. its irrelevant that the file is
autogenerated for the first time, if it lives in /etc/ its a
configuration file and admin changed MUST be preserved.
i cite policy:
4.7.3 Behavior
Configuration file handling must conform to the following behavior:
* local changes must be preserved during a package upgrade
note that earlier the distiction is made between conffiles and
configuration files. this rule applies to both.
> > this violates policy.
>
> As far as I can see, policy allows automatic building of a
> configuration file [1]. I have to admit that right now this automatic
> build process leaves a lot to be desired. Expect something [2] next
> week.
automatic bulding of configuration files is allowed, but the admin
MUST be permitted to change them outside of debconf. if your package
blows away my hand made changes it violates policy.
if it lives in /etc im allowed to modify it and you must not trash my
changes. debconf is NOT a registry.
> > the ones avialable now kept destroying my config file as i upgraded
> > the packages a few times getting my potato hacks working right...
>
> Sorry 'bout that, but please keep in mind that it is not normal to
> upgrade a package three times a day after meals. Those packages are
> work in progress, and once they are finished, they will be upgraded
> with every upstream version on unstable/testing systems and with every
> Debian release on stable systems.
i realize they are a work in progress, but i am making it clear: the
final packages must NEVER under ANY circumstances destroy local
changes made to the configuration files, namely /etc/molrc. i don't
care what debconf was told to do at initial install, that is
irrlevant, and policy requires that it not destroy my changes. if it
does that warrents a severity: serious bug report.
> Then you should uncheck the debconf option and build the video modes
> database by hand before running mol for the first time.
this is not the point, at first install its logical to run this
utility in the postinst, rerunning it on upgrades is unecessary and
quite irritating.
> But probably the postinst script should ask before actually starting
> molvconfig. After all, we don't want a program running as root that
> simply pops up on the console during a remote or, worse, unattended
> upgrade.
indeed, this will break on ssh sessions. AFAICT this utility also
provides no means to exit out without destroying the molvconfig. it
should probably be patched to fix that.
> [1] Debian policy Manual 3.5.4.0, Chapter 8, paragraph `The hard method ...'
i am looking at potato's policy package, but i have no reason to
believe that newwer policy allows for local configuration file chnages
to be destroyed by debconf under any circumstances.
see recent rants by joey hess and the lilo debacle for more details...
--
Ethan Benson
http://www.alaska.net/~erbenson/
Attachment:
pgpEQO1CBAojE.pgp
Description: PGP signature