improving rpm

[Nicolas Mailhot]

Le mercredi 12 juillet 2006 à 21:12 +0100, Cam a écrit :
> Nicolas
> 
> >> 2) Attempt to merge changes, in the manner of a modern revision control
> >> system.
> > 
> > This is a 100%-proof recipe for disaster, even if conf files where all
> > in structured format like XML with full grammar available
> 
> I don't think it has to be a disaster.
> 
> If a package is frequently updated, or has a large config file which has 
> minimal changes, then I imagine the logic to patch the config file would 
> be simple.

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

> If the situation is complex, we can detect it and make suggestions.

rpm is designed to run unattended

> Maybe even fall back to existing behaviour.

the existing conf file may be invalid for the new version of the app.

> I think it's an interesting idea. What's the harm in offering the user 
> the choice between new config, old config, merged changes?

rpm is designed to run unattended

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.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060712/b0373e04/attachment.sig>