RPM roadmapping

[Theodore Papadopoulo]

Ian Burrell wrote:
> Having the clean config files make it easier to manage them with
> version control.  They can be used for doing a three-way merge or for
> making the vendor branch.
>
> Instead of having rpm do the copy, it might make sense to have a hook.
>  The default hook would copy the files but somebody could have it call
> a version control system.
>   
Considering config files and orthogonally to the version control 
proposal, a feature I would like to have is a way for
a rpm package to override some config files. I'm not sure if it is at 
all feasible or even whether there is not
a tricky way to do it currently.

The use case is the "customisation" using rpms of a group of machine for 
which it is needed to modify some config files
belonging to some other rpm. A maybe not too good example would be to 
modify /etc/yum.repos.d/fedora*
to add eg some local mirror. Right now, this is impossible as those 
files belong to the redhat-release package (as of FC5), so
pushing such a modification requires creating a new version of this 
package, which is definitely not clean.

The attribute %config(noreplace) is of no use in such a case.

The idea would be something like this. Assume that package A.rpm owns a 
config file A.conf. Extend
rpm so that it is possible to create a special package B.rpm (modifiers 
rpms or overriders rpms ??) that just contains
modifiers or overriders of A.conf. A.conf remains owned by A.rpm. B.rpm 
obviously should depend on A.rpm.

- If A.rpm is removed that means that B.rpm has to be removed.
- If A.rpm is updated, there should be a policy of how B.rpm should be 
managed. The most flexible way would be
  to allow the spec to decide among various options (block the upgrade, 
reapply a patch, re-override the config file
  or keep the new config file, remove B.rpm and emit a warning).

I do not know if this is at all feasible in a sensible way, but 
something allowing the configuration of multiple machines
would really be helpful.

    Theo.