Re: we need more variation for conffiles
>>"Atsuhito" == Atsuhito Kohda <kohda@pm.tokushima-u.ac.jp> writes:
Atsuhito> From: Manoj Srivastava <srivasta@debian.org>
Atsuhito> Subject: Re: we need more variation for conffiles
Atsuhito> Date: 16 Feb 2000 04:49:00 -0600
>> Do we need to change the mechanism, really? Can't the package
>> ask, in the postinst, to make changes anyway? ideally, the postinst
>> can make the changes without losing the users local changes. At
>> worst, the user is informed by the postinst that the new, improved,
>> fixed postinst lies in /usr/share/doc/<pkg>/something.
>>
>> You need only ask the user of you detect a broken conffile.
Atsuhito> Yes but I think these methods might need an extra burden of
Atsuhito> the user.
I still think that overridden by default files should *not* be
conffiles. Conffiles are files that users have been assured shall
*not* be overwritten up upgrade -- so go ahead and make changes.
Frankly, if you know before hand that any changes you make
to some part of the file should override the users changes, pull
thoise parts out into a non0conffile that is included.
So asking the user when you have badly broken a conffile is
should not happen bery often. In fact, hardly ever. And then asking
and letting the user decide is not asking too much of the user. These
are extraordinary circumstances, after all.
And I would much rather that the user be asked than we assume,
like microsoft, that these things are too much for the user to
handle. Users are paople too, and a well phrased question (with a
decent default) is not going to be too onerous (if it is, then
perhaps they are using the wrong operating system).
>> Frankly, by not making scripts conffiles we can go a long way
>> towards avoiding problems.
>>
>> And when problems do arise, I think a well written postinst
>> can fix the issue.
Atsuhito> But I think this needs pretty good efforts for the maintainer
Atsuhito> and the results might be satisfactory or not depending on the
Atsuhito> ability of the maintainer.
I assume that Debian developers are at least marginally competent.
>> We may need toreexamin the conffile handling in the future, I
>> am just not convinced that we have been rpesented with a compelling
>> argument yet.
Atsuhito> I do not intend to say that "the conffile replaced by default"
Atsuhito> is the unique method or the best method. I should repeat the
Atsuhito> sentence; that depends on the packages.
I am pretty much convinced that replacing a conffile be
default is never really the best solution, but I can still be swayed,
perhaps by examples. (I would not object if there was a way that dpkg
presented the conffile with a different default, but only for a
specific version, if so asked by the maintainer of the package (we
have to find some way of stating if upgrading from a version older
than ...).
I would not find having a particular conffile routinely be
replaced be default acceptable.
So, if we could ask, in cases of serious problems, that dpkg
replace the conffile as a default action, I would not object,
espescially if one had to type in a confirmation.
Atsuhito> Certainly there are cases in which a well written postinst
Atsuhito> is appropriate and some cases in which providing
Atsuhito> information to the user is appropriate; and don't you think
Atsuhito> that there might be cases in which "the conffile replaced
Atsuhito> by default" might be appropriate?
I have not been able to convince myself that such a case
exists, no. All the scenarios I could come up with could be solved by
a proper preint/postinst. However, in theory, I may grant you that in
xome cases it may make sense for the default action to be replace.
Atsuhito> I think it might help both the maintainer and the user in some
Atsuhito> cases.
Ok. This is a different kettle of fish, as they say, than what
you said before. As long sa you stipulate that these cases occur i
exceptional circumstances.
manoj
--
A horse breeder has his young colts bottle-fed after they're three
days old. He heard that a foal and his mummy are soon parted.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: