Updates overwriting configurations - Warning from CentOS

[miyasuka]

Firstly thank you for all the hard work behind the Atomic repo.

We're considering using Atomic to keep a LAMP stack up to date on a production server for a client with high security requirements. One of the scripts on the server requires the ioncube boot loaders which is what brought us to Atomic. However we notice that on the CentOS wiki they warn users about the Atomic repo, specifically with regards to updates overwriting config files. I'm sure there must be a very good reason for this, would you mind explaining to me why you do this and what solution you recommend to keep custom config files between updates.

The line below is an extract from their wiki:

Be particularly careful about the Atomic repo as they enable their repo by default when installed, and overwrite user changes in the configuration without notice when the release package is updated. Atomic will replace many core packages as configured when installed.

[scott]

Some misunderstandings on their part I suppose:

1) Atomic is about updates to core packages, like php and mysql. When the archive was launched in 2002, it was specifically for that purpose. So while I understand from their perspective that changing a core package is against their mission, Atomic was around long before Centos existed and it was always been our mission to bring in new technology to the redhat platform.

2) Config files (/etc/php.ini for example) are tracked as %config just like any other package distributed by redhat. These would never be replaced by an update, so Im not sure where they got that idea, it just not true. If an update occurs, the new config file will be added as <originalname>.rpmnew

[faris]

Be particularly careful about the Atomic repo as they enable their repo by default when installed, and overwrite user changes in the configuration without notice when the release package is updated. Atomic will replace many core packages as configured when installed.

Actually, this is (or was) factually correct - but not in the way that most people would understand it at first sight.

What they are saying is in fact:

1) When you install the atomic repo, the /etc/yum.repos.d/atomic.conf file has enabled=1 by default
[My comment -- why would anyone want it to be disabled by default? If I install a repo via rpm or shell script I do expect it to be enabled by default. I'm not sure why they even made this comment]

2) When there is an update to the atomic-release-*.rpm, any user-made changed to the contents of /etc/yum.repos.d/atomic.conf are liable to be overwritten
[My comment: I think this did happen once, a long long time ago, possibly in the stone age, in a galaxy far, far away. It doesn't happen anymore, as far as I'm aware? Even if it does, it is unlikely to cause a problem. For example if an exclude= line gets removed, I would notice when doing a yum update]

3) The stock Centos-provided packages such as MySQL and php will be replaced by much newer versions.
[My comment. Yes, well, this is one of the main purposes of the Atomic repo, and 99% of the time this is a good thing. It provides MySQL 5.5, instead of 5.1, for example. php is a different kettle of fish. Until recently, it provided a most wonderful version of php 5.3. But 5.3 is now EOL and so the Atomic repo now provides php 5.4 instead. This is awesome for many people, but not what I personally want due to too many of our user's scripts being incompatible with 5.4. But that's no big deal. All I need to do is add exclude=php* to the appropriate section of atomic.conf OR I can subscribe to the Atomic-Nucleus repo ($subscription required) and get a superior than Centos-stock php 5.3 with regular fixes].

Anyway, what that quote is NOT saying is that user configuration files (e.g. /etc/php.ini) get overwritten. As Mike says, they don't. If appropriate, you get an .rpmnew version containing the new default config for the application in question, which you can then use, ignore or merge with your current config file as required.

But Regarding the ioncube loader - if that's all you need (i.e. you don't need php 5.4 as well), you might be better off installing it manually? Or am I being over-cautious here? Someone else will no doubt set me straight, or agree with me.

[scott]

php-ioncube-loader is unique in that since its a binary package, its going to be compatible with all versions of php. In almost every other case, the php x86_64 / i386 packages in atomic would be linked against the current build of php.