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
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
