improving rpm

[Tomasz Kłoczko]

Dnia 12-07-2006, śro o godzinie 15:24 -0400, Neal Becker napisał(a):
> rpm has served us well, as have the tools that have grown around it (yum,
> smart, etc.).
> 
> One thing that is not currently addressed well is how to track local changes
> to config files.  For now, rpm just punts, and not very intelligently. 
> When a package is updated, it just creates either config.rpmnew or
> config.rpmsave.  It is not intelligent - it creates these unconditionally
> even if there is no actual change to the installed file.
> 
> I used to try to check these and see if there were important changes - but
> now I just do what probably 99% of you do, which is just ignore it and hope
> nothing breaks.
> 
> I was quite interested when I saw the announcement of conary, which solves
> this problem by allowing local changes tracked as patches.

Not 100% right but IMO patch it is only another form of *.rpm{new,save}
files. For fully automated update procedures better will be extend rpm
current %trigger* script by kind of %update.
Why ? because current syntax of for example most often used %
triggerpostun is:

%triggerpostun -- <package_name> [< <version>]

instead of:

%update <versionA> <versionB>

which IMO will allow implement more precise framework for adding better
update (for example config files) procedures.

Also next thing ..
Now there is no place in rpm database where are stored all original %
config files contents. It is necessary now if rpm must be usable as PM
for Solaris 10 with zoning but .. not only for Solaris. Also will be
necessary on Linux on create by replicate any system images from system
installed files for Xen or VT implementation similar to Solaris zoning
in case non-shared part between main system resources and Xen/VT/zone
subsystem.
Why ? because many cases create this kind images requires on initial
replication %config files in original form.
If in rpm database will be stored original file (not only md5/sha
digest) create *.rpm{new,save} or patch file can be done as rpm config
parameter (stored for example in /etc/rpm/rpmrc).

Also keep in rpm database all original %config files will allow faster
maintenance system in case some bad changes or mistake removing this
kind files.

Also have some kind of infrastructure in rpm for allow commit change in
%config file to rpm database will allow:
- keep track of changes in %config files (for better system
  maintenance),
- prepare better automation for update %config files on upgrade.
Keep in rpm db changes as patches series with short comments or even as
RCS blob will be probably all what is necessary (more sophisticated VC
system will be probably overkill).

kloczek