Nicolas
Except you can't assume the user will always do a n -> n+1 upgrade and
not wait several years before doing a FCn -> FCn+X update
Except you can't assume the user didn't change the conf file manually
between updates
Except many conf files allow you to express the same thing in different
ways, so you have to actually parse and understand the meaning of a file
before safely patching it.
Except sometimes configuration is stacked with conf.d and other such
things so you need to parse all the other files too before changing one
of them
Except you need to track non-active info such as comments
All valid reasons why an automatic merge may not be possible in all
cases. That's not to say that it wouldn't work in many cases, or that it
would be somehow worse than not bothering at all.
If the situation is complex, we can detect it and make suggestions.
rpm is designed to run unattended
That needn't change. rpmsave and rpmnew are suggestions, and the file
that remains after update is the best guess. Interactivity would be a
nice bonus for a modern OS but needn't be a deal breaker.
If you want to have a small idea of what "patching conf files" really
means I invite you to read the dejavu rpm spec. And I'm only doing small
changes on a conf file with very few verbs, stable grammar, no
interactions between conf directives, and structured content.
I'm not sure how closely an rpm spec would match a realistic use case
for end user OS administration. But even so, going from one version to
the another, and applying a patch (adding a few lines, deleting some or
changing them) could either patch successfully, or fail. In the event of
failure we have an 'rpmsave'.
-Cam
--
<--
camilo@xxxxxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
