Update strategies (was Re: [TriLUG] Re: Newbie question reguarding YUM and Linux.)

[Rick DeNatale]

On 1/11/06, Tanner Lovelace <clubjuggler at gmail.com> wrote:
> On 1/11/06, Jason Faulkner <jasonlf at gmail.com> wrote:
> > (I haven't used RH in a while, so correct me if I'm wrong)
> >
> > Doesn't RH automatically replace config files saving the old as
> > .rpmsave when they change? That to me is reason enough not to auto
> > update.
>
> The behavior of how rpm based distributions handle config files is fairly
> complex and not well understood.  It all depends on if the files are
> specified as config files in the RPM file list.  If they aren't, they are
> blindly overwritten, no questions asked, nothing saved.  Since this
> has to be done by hand (or at least up until I quit working with
> RPM spec files regularly), there is lots of room for error here.
>
> But, assuming the config files are correctly specified in the rpm spec
> file, then it depends on if you specify %config(noreplace) (iirc, since
> I'm probably rusty on this) then the new file will be added as
> configfilename.rpmnew.  I don't remember under what conditions
> it will replace the config file and rename the older one as
> configfilename.rpmsave, but that exists too.
>
> This all comes about because of the requirement for RPM packages
> to be upgradable without user input.  Using something like debconf,
> which Debian uses, gives you more options in how you want to treat
> config files with the tradeoff that now you must babysit the process
> much more, so it's still hard to say which one is better.  (And, most
> likely, neither is really "better", they're just different philosophies.)

I think that there's more to the difference between RPM and debian
based systems besides this PARTICULAR difference of philosophies.

As one who has made the switch from RH/FC to Ubuntu, albeit with only
a few years of experience with the former, and a now bit less than a
year of experience with the latter.  One of the things which struck me
about the debian system architecture is that in many cases there
appears to be a good deal of thought given to modularizing packages,
including config files. Most of this springs from the debian policy
manual which puts restrictions on package maintainers with the goal of
making the system maintainable, updatable, and upgradeable.


For example, under redhat up to the point I switched, the apache
config file was pretty much a monolith.  In the debian packaging, the
main config file is set up to include pieces by iterating over files
in a conf.d directory.  They also use a mods-enabled directory, and a
sites-enabled directory with links to config files for apache modules
and virtual hosts respectively. For one thing this allows packages of
web applications, or optional apache modules to keep their
configuration separate from the base apache configuration. Similarly
it aids sysadmins keep local modifications outside of the base
configuration.

FWIW, I can't recall seeing apt-get/dpkg prompt ME for anything
outside of initially installing a package.  It's more likely to happen
during a system upgrade when a new upstream major version of a package
might have made incompatible changes to the config file syntax.

Of course that's just my own experience, and it might change tomorrow
for all I know. <G>
--
Rick DeNatale

Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/