Bug 51335

Summary: initscripts should depend on SysVinit
Product: [Retired] Red Hat Linux Reporter: Filip Van Raemdonck <mechanix>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: mechanix, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-08-09 15:59:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Filip Van Raemdonck 2001-08-09 15:59:32 UTC
Description of Problem:

initscripts' /etc/init.d/functions uses pidof, which is in SysVinit.
However initscripts does not depend on SysVinit either directly or through
I need to build rpms from time to time, and do this on a Debian system
inside a chroot. When I build an rpm that needed to start a service, and
tested it inside this chroot, startup failed because it didn't have SysVinit.

How to reproduce:

Here's the list of packages I have installed to build the package:

MAKEDEV autoconf automake basesystem bash binutils bzip2 bzip2-devel
chkconfig cpp cracklib cracklib-dicts db1 db2 db3 dev diffutils e2fsprogs
ed file filesystem fileutils findutils gawk gcc gcc-c++ gdbm glib glibc
glibc-common glibc-devel gnupg grep gzip info initscripts kernel-headers
libstdc++ libstdc++-devel libtermcap libtool libtool-libs logrotate m4 make
mingetty mktemp modutils mount ncurses net-tools pam passwd patch perl popt
procps psmisc pwdb rpm rpm-build rpm-devel sed setup sh-utils shadow-utils
slang strace sysklogd tar termcap textutils util-linux vim-common
vim-minimal which words zlib zlib-devel

None of these depend on SysVinit. I installed my package, it went ok,
started the service, worked fine, stopped the service, failed because it
couldn't find pidof.

I know this isn't the most common situation, but just think of someone who
does actually use Redhat, and wishes to use a chroot for some services as a
security measurement. He will run into the same problem.


PS. How acceptive are you to new packages? I generally don't care about
things I package for Redhat systems, as they are usually to fullfill very
specific needs, but this one is rather general-purpose and I think it could
be a useful addition.

Comment 1 Bill Nottingham 2001-08-09 16:11:39 UTC
Will be fixed in 6.13-1; thanks for the feedback!