xinetd and chkconfig - ok to upload ?

Charles Wilson cwilson@ece.gatech.edu
Mon Dec 30 12:40:00 GMT 2002


Short version:
as far as MY concerns go, these two packages are ok for upload.

> On Tue, 24 Dec 2002, Pavel Tsekov wrote:
> 
>> 1. xinetd
>> 
>> version: 2.3.9-1
>> status : reviewed; ready for upload (?!)
>> 
>> 2. chkconfig
>> 
>> version: 1.2.24h-1
>> status : reviewed; ready for upload
> 
> Does anyone have any objections if I upload this packages ?
> 
> I've doubts only about xinetd. Sergey answered Charles's question and 
> there was no response from Charles, so it should be ok, right ?
> 

Yes, I guess so.  There were two separate subthreads -- one on xinetd 
and one on chkconfig, but Sergey answered some but not all of the 
questions all in one reply.  However, the questions he left unaddressed 
were not showstoppers.

Concerning xinetd, http://cygwin.com/ml/cygwin-apps/2002-12/msg00114.html
addressed most of the issues.  Sergey explained that a preremove script 
couldn't do this:
(*) rm -f /etc/xinetd.d/*
(*) rmdir /etc/xinetd.d
(*) rm -f /etc/xinetd.conf

but he never said why it couldn't at least do this (since I had 
suggested all six operations):

rm -f /usr/bin/xinetd-config
chkconfig --del xinetd 2>&1 >/dev/null
rm -f /etc/rc.d/init.d/xinetd

As it turns out, ONLY the first action in the second group (rm -f 
/usr/bin/xinetd-config) can actually be done from a preremove script, 
since xinetd-config will be automatically and unconditionally replaced 
by the postinstall script if this is an upgrade, and not an actual removal.

However, the other two actions in the second group -- creating 
init.d/xinetd and making the rc.N/symlinks -- are only done when the 
user explicitly runs /usr/bin/xinetd-config.  Thus, on upgrade, if the 
preremove script removes those, the user will have to re-run 
xinetd-config to recreate that file and symlinks.

Blech.

I don't think there is a clean way to do this (and ssh doesn't clean up 
/usr/bin/sshd-*-config either) unless we have a set of scripts like

/etc/postinstall/
/etc/postupgrade/
/etc/preupgrade/
/etc/preremove/

and setup "knows" about upgrades vs. removals, and calls the "correct" 
scripts.  But that's a MESS -- and would probably break a lot of 
existing packages that depend on the current behavior for proper 
operation on upgrade/install/remove.  I'd rather leave a few droppings 
around after an "real uninstall" and let upgrades remain simple.

There was also an issue with sunrpc:

Sergey said:
 > Me too. I'd like to build rpc-aware xinetd with sunrpc package.

I'm not sure if that means he wants to WAIT for the sunrpc package to be 
accepted into cygwin, then rebuild his xinetd package so that it uses 
the rpc stuff, or if he wants to go forward with xinetd AS-IS and add 
rpc stuff later on as an update.

I suspect the latter.

So, as far as MY concerns go, these two packages are ok for upload.

--Chuck




More information about the Cygwin-apps mailing list