While trying to rebuild Squid on Red Hat 6.0, I noticed the following
discrepancy in the specfile:
Prereq: /sbin/chkconfig logrotate shadow-utils /etc/init.d
mkdir -p $RPM_BUILD_ROOT/etc/rc.d/init.d
install -m 755 $RPM_SOURCE_DIR/squid.init\
Fix: change Prereq to /etc/rc.d/init.d or fade out support for the non-FHS-
compliant /etc/rc.d totally. :-}
Phasing out support for /etc/rc.d entirely is easier said than
done. It presents some, um, *interesting* technical issues
with RPM and upgrades.
Feel free to explain, I'm very interested.
RPM, when installing multiple packages, does it as a single big 'transaction'
glob. It determines beforehand whether each particular file will be backed
up, removed, left alone, etc, by looking at the pathnames that will exist
once the packages are added/removed.
Now, to support backwards compatibilty with a new /etc/init.d layout, you
need to do more or less (in the initscripts %pre):
mv /etc/rc.d/* /etc
ln -s /etc /etc/rc.d
and have all new packages require the new initscripts.
OK, so you have your package foo, with the new layout. It will be installed
in the same transaction as initscripts.
So, we start looking at file states:
old package has /etc/rc.d/init.d/foo
new package has /etc/init.d/foo
Obviously, /etc/init.d/foo will be created. RPM looks and sees that
/etc/rc.d/init.d/foo won't be owned by anything after the upgrade,
so it marks it for removal.
So, initscripts is installed in the transaction, and the directories
are moved. Then package foo comes up. /etc/init.d/foo is created, and
then /etc/rc.d/init.d/foo is removed - it follows the symlink, and
*poof* the initscript you just installed is gone. Repeat for every
package installed in the transaction set after initscripts.
One solution is to have the file state determination engine take into account
filesystem changes made in scriptlets. However, that's a non-trivial amount of
code to write, and it's impossible to cover all cases when scriptlets can
be passed through an arbitrary interpreter.
Basically, all this was discovered between 6.2 and 7.0 when we attempted
to make this switch. :)
Thanx for taking the time to explain that. Very interesting. So I think we could
call it NOTABUG :->
BTW... am I right that there is no possibilty to add and remove a package in the
same rpm run? I always have the problem when replacing sendmail with postfix,
because sendmail provides "smtpdaemon" which is required by some other packages
like MUAs etc. So I have to rpm -e --nodeps sendmail and after that rpm -i
postfix. I see no way to do that in _one_ rpm run so that RPM sees, that
smtpdaemon is still provided after the replacement. Should I file an RFE for rpm
to cover that?