Re: RPM - Preventing uninstall and file conflicts.

Jos Vos wrote:
> Hajducko, Steven wrote:
> > I've had to do the test installs with --force, as some of these files (
> > /etc/ntp.conf ) are owned by other packages ( ntp ).

I tried doing what you are now trying to do some time ago.  My
experience from it led me away from packaging configuration files as a
system management technique.  I now believe it to be good experience
about how not to do things.  Instead I would manage configuration
files through other means where the root of that would be based in
revision control.  (But that gives a lot of flexibility and leeway.

> > NTP actually isn't too much of an issue and could be repackaged,
> > but other RPMS such as 'setup', a RHEL specific RPM, is not
> > repackagable ( to my knowledge ).
> 
> Everything can be repackaged, every RHEL rpm has a src.rpm (except for
> some in the supplementary - proprietary - channel), but that's a lot of
> work and a bad idea to do.

I would not repackage everything because it creates such a support
issue.  Let's say you are trying to run a 3rd party application but it
has certain requirements and you need support for it.  As soon as the
system is examined it will be found to be no longer a supported
system.

> There is a simple and elegant way to do this: use trigger scripts.

A good suggestion.  All of the notes there I mostly agreed with.  It
is not a bad way of doing things.

But actually I think putting configuration in packages is very heavy.
It makes making changes to the configuration a more labor intensive
process because new packages must be created.

> This is my "network-wide system management by RPM" guide in short ;-).

I want to emphasize that I think that list was all quite good!  I want
to emphasize this because I am going to suggest that creating packages
for configuration, while a solid and reliable system, is too heavy.
Therefore I would not do it.  I think it is better to keep the scripts
that configure the system in version control.  To be clear I think it
is better to keep the scripts that set /etc/ config files in version
control, not the /etc/ config files themselves in version control.

I agree completely that using scripts to edit the configuration files
on the machine is definitely the way to go.  But instead of putting
them in packages I would have them in version control and have the
system check them out from version control before running them.  The
framework to implement this may certainly be put in a package and
distributed that way.  But then when system changes are required I
would make the changes in version control and let them propagate.

A good place for further information on this type of thinking is the
Infrastructures site.  Browse around there, perhaps join the mailing
list for discussion, and see what you think.

  http://www.infrastructures.org/

Bob