This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: xinetd and chkconfig - ok to upload ?


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]