Changing of behavior: How to tell the user?
Dear Mentors, I'm the maintainer of the CVSNT package. This is a better replacement for CVS and just like CVS it can work as server or client. One of the enhancements (on the server side) was replacing the old directory based file locks with a so-called lock server, which handled all the locking on a per file basis. What I did until now was to start this cvslockd daemon in an init script regardless whether the user used CVSNT as client or server. In the next few weeks should now come out a new version upstream and I updated my package, fixed the bugs and I also want to prevent that cvslockd is started every time. So I created a configuration file /etc/defaults/cvsnt where an environment variable defines whether or not the daemon gets started. I figured that there are probably more client users than server users and set the default to no longer start cvslockd. My questions: 1) Is this change of behavior desirable/do-able? 2) Is /etc/default/cvsnt the right place to turn on/off the daemon at all? 3) How shall I inform the server users that they know that they have to configure the file to get the lock daemon started again? TIA and best regards Andreas -- (`-''-/).___..--''`-._ `o_ o ) `-. ( ).`-.__.`) (_Y_.)' ._ ) `._ `. ``-..-' _..`--'_..-_/ /--'_.' .' (il).-'' (li).' ((!.-' Andreas Tscharner [EMAIL PROTECTED] ICQ-No. 14356454 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Changing of behavior: How to tell the user?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Tscharner wrote: Dear Mentors, I'm the maintainer of the CVSNT package. This is a better replacement for CVS and just like CVS it can work as server or client. One of the enhancements (on the server side) was replacing the old directory based file locks with a so-called lock server, which handled all the locking on a per file basis. What I did until now was to start this cvslockd daemon in an init script regardless whether the user used CVSNT as client or server. In the next few weeks should now come out a new version upstream and I updated my package, fixed the bugs and I also want to prevent that cvslockd is started every time. So I created a configuration file /etc/defaults/cvsnt where an environment variable defines whether or not the daemon gets started. I figured that there are probably more client users than server users and set the default to no longer start cvslockd. My questions: 1) Is this change of behavior desirable/do-able? 2) Is /etc/default/cvsnt the right place to turn on/off the daemon at all? 3) How shall I inform the server users that they know that they have to configure the file to get the lock daemon started again? TIA and best regards Andreas for 3) - may be, Debian.NEWS and/or debconf message in postinst? - -- Eugene V. Lyubimkin aka JackYF -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh/YesACgkQchorMMFUmYw3egCeKr2kyaAt5JMohn2W5bCiySzs ph0AnRpiZsqDU2cTMm40J/oJ38zPWtCz =5Ufe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Changing of behavior: How to tell the user?
On Thu, Jul 17, 2008 at 06:14:51PM +0300, Eugene V. Lyubimkin wrote:
Andreas Tscharner wrote:
Dear Mentors,
cvslockd is started every time. So I created a configuration file
/etc/defaults/cvsnt where an environment variable defines whether or not
the daemon gets started. I figured that there are probably more client
users than server users and set the default to no longer start cvslockd.
My questions:
1) Is this change of behavior desirable/do-able?
I like that change, as I typically install cvsnt and then
rm -fv /etc/rc?.d/S??cvsnt.
2) Is /etc/default/cvsnt the right place to turn on/off the daemon at all?
I think so.
3) How shall I inform the server users that they know that they have to
configure the file to get the lock daemon started again?
for 3) - may be, Debian.NEWS and/or debconf message in postinst?
Another option is to create (only if it doesn't exist, and after doing
a version number comparison with dpkg --compare-versions to see if
this is a version where it should be created) /etc/defaults/cvsnt as a
non-conffile configuration file, with the value CVSNTD determined by:
. if it's an initial installation, no;
. otherwise, detect if cvslockd is running with s-s-d:
postinst:
f=/etc/defaults/cvsnt
v=2.5.03.2382-3.3
[ ! -e $f ] dpkg --compare-versions $2 le $v {
CVSNTD=no
[ -n $2 ] start-stop-daemon --quiet --stop --test -n cvslockd -x
/usr/bin/cvslockd CVSNTD=yes
echo Creating /etc/defaults/cvsnt with CVSNTD=$CVSNTD 2
echo CVSNTD=$CVSNTD $f
}
Perhaps you could do something a bit more sophisticated, instead of
doing [ ! -e $f ] you could do:
grep '^[[:space:]]*CVSNTD' $f /dev/null || {
dpkg --compare=-versions $2 le $v {
CVSNTD=no
[ -n $2 ] start-stop-daemon --quiet --stop --test -n
cvslockd -x /usr/bin/cvslockd CVSNTD=yes
echo Initializing /etc/defaults/cvsnt with CVSNTD=$CVSNTD 2
echo CVSNTD=$CVSNTD $f
}
}
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Changing of behavior: How to tell the user?
On 2008-07-17 17:56 +0200, Justin Pryzby wrote: Another option is to create (only if it doesn't exist, and after doing a version number comparison with dpkg --compare-versions to see if this is a version where it should be created) /etc/defaults/cvsnt as a non-conffile configuration file, with the value CVSNTD determined by: . if it's an initial installation, no; . otherwise, detect if cvslockd is running with s-s-d: AFAICS, this last option won't quite work in the postinst, because dh_installinit's snippet stops the daemon in the prerm script, see #471060. But maybe it can be used in the preinst instead. Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
