improving rpm

[Cam]

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 at mesias.co.uk