[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: improving rpm


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'.



camilo mesias co uk

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]