On Fri, Feb 27, 2009 at 01:35:56PM +0100, Dominique Dumont wrote:
> I think your numbers are right. The main problem I see is that the
> automatic merge will not be able to inform the user whether the
> merge is correct or not. In case of merge failure, the application
> will exit on error and leave the average user in the dark. Even 10%
> of this kinf of failure will be badly perceived.
I agree with this argument, but I contend that it would be no
regression: currently, would the user know that after having chosen to
preserve the installed version of a conffile (instead of the
maintainer version) that configuration can be wrong wrt the new
version of the package being installed?
She wouldn't know, where is the difference?
(Yes, I know you are proposing an improvement over that situation, but
it is not for free, since it requires a per-conffile-kind
development. Mine is conffile-kind-independent and I believe it wont
introduce any regression.)
> > But then we are back at the issue of a 80-20 problem, and I see
> > the VCS solution as more flexible and more readily available.
>
> Agreed. But VCS solution is a 80% success/20% silent
> failure. Config::Model is a 80% success/20% abort. The latter should
> be easier to deal with for average user.
With my former argument, that 20% of silent failures is possibly very
comparable with the silent failures enabled by the current status. I
stop before the temptation of repeating:
> > But again, it looks to me that the two approaches can coexist.
>
> Absolutely: Something like try Config::Model, if it fails (missing
> or incomplete model) may be VCS merge with mandatory user
> interaction or usual ucf question.
:-)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature