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

Re: RPM roadmapping



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.


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