mirror of
https://github.com/xcat2/xcat-core.git
synced 2026-09-02 15:36:03 +00:00
Vinícius Ferrão
2487faa678
xcat.conf was installed as an ordinary payload file and then deleted and recreated from the Apache-version template in %post. rpm therefore held no record of what was on disk, and an upgrade replaced an edited file silently, leaving neither .rpmnew nor .rpmsave. A site that had added Indexes to the /install block lost it on upgrade and directory listings began returning 403. Select the Apache 2.2 or 2.4 configuration at build time, using the same distribution macros the rest of the spec already relies on, and mark both /etc/httpd/conf.d/xcat.conf and /etc/apache2/conf.d/xcat.conf as %config(noreplace). rpm then keeps a modified file and installs the new vendor version alongside it as xcat.conf.rpmnew. The old payload recorded the 2.2 file while %post wrote the 2.4 one, so rpm cannot distinguish a stock file from an edited one across the transition. A migration compares the active file with the templates the outgoing package saved under conf.orig and removes it only when it is a regular file still byte-for-byte identical to one of them. A stock upgrade then completes without an unnecessary .rpmnew, and anything that differs is left untouched. That migration runs in %pretrans, not %pre. rpm fixes each config file's fate before %pre, so removing the active file there can happen after rpm has already resolved to write only xcat.conf.rpmnew, leaving the system with no active configuration at all. %pretrans runs before that decision. It is an embedded Lua scriptlet because a pre-transaction scriptlet cannot rely on any dependency being unpacked yet, which also means the comparison needs no external tool. bc was needed only by the version check the service-node package no longer performs. The Apache directives are unchanged. Document a later-loading conf.d file as the place for site rules, since that survives upgrades without a merge.