Bug 21267

Summary:	[2.3.STABLE4-2] discrepancy /etc/init.d <-> /etc/rc.d/init.d
Product:	[Retired] Red Hat Raw Hide	Reporter:	Daniel Roesen <dr>
Component:	squid	Assignee:	Bill Nottingham <notting>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	1.0	CC:	rvokal
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-11-28 05:36:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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\
 RPM_BUILD_ROOT/etc/rc.d/init.d/squid

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

OK.

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?