Re: Proposal to improve package configuration upgrades
Stefano Zacchiroli <email@example.com> writes:
> Well, it depends on how dpkg currently handles merges. My impression
> (as a user, never looked at the actual code) is that it not even tries
> to merge, it simply discovers that the local file is not pristine and
> then asks the user. On the contrary, every VCS I'm aware of at least
> _tries_ a merge, "succeeding" when changes do not affect the same
> patch hunk.
> Also, there is of course no guaranteed that no conflicting changes
> lead to a configuration file semantically sound,
That's the main problem I see with VCS like merge. The main problem is
that the merge result *should* be reviewed by the user. Will the user
always have the skills to spot the places where the merge was wrong ?
> but AFAIU you have no guarantee of that with Config::Model
> either. They are both about syntax only.
No Config::Model is all about checking the *semantic* of a
configuration file. So you will have the guarantee that the resulting
file is correct from the application point of view.
>> >From a user point of view, you will get the same diff output whether a
>> SCM performs the diff or ucf performs the diff.
>> So your proposal will probably not help my mother-in-law to upgrade
>> the packages on her system ;-)
> I disagree. It will not help your mother-in-law once she is faced with
> the diff, but it will decrease dramatically the number of times she
> will be faced with that. ... so maybe we should strive for both?
There's may be cases where the merge completes automatically but the
end result is wrong. That would be really bad.
All the best
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner
domidumont at irc.freenode.net
ddumont at irc.debian.org