Bug 21267 - [2.3.STABLE4-2] discrepancy /etc/init.d <-> /etc/rc.d/init.d
Summary: [2.3.STABLE4-2] discrepancy /etc/init.d <-> /etc/rc.d/init.d
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: squid   
(Show other bugs)
Version: 1.0
Hardware: All Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-11-22 21:30 UTC by Daniel Roesen
Modified: 2014-03-17 02:17 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-11-28 05:36:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Daniel Roesen 2000-11-22 21:30:06 UTC
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. :-}

Comment 1 Bill Nottingham 2000-11-22 21:50:35 UTC
Phasing out support for /etc/rc.d entirely is easier said than
done. It presents some, um, *interesting* technical issues
with RPM and upgrades.

Comment 2 Daniel Roesen 2000-11-22 22:13:11 UTC
Hehe :-]

Feel free to explain, I'm very interested.

Comment 3 Bill Nottingham 2000-11-28 05:35:55 UTC

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
rmdir /etc/rc.d
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. :)

Comment 4 Daniel Roesen 2000-11-28 14:22:11 UTC
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?

Note You need to log in before you can comment on or make changes to this bug.