On Sun, Mar 16, 2008 at 03:00:49AM +0100, Michael Biebl wrote: > Craig Sanders wrote: > > On Sun, Mar 16, 2008 at 01:16:22AM +0100, Michael Biebl wrote: > > > > >> grep "invoke-rc.d .* stop" *.prerm > > > > 1. the fact that some other packages have the same or similar broken > > behaviour as yours does not excuse or justify your package being broken. > > You are talking about "some", while it clearly is the majority of the > packages that uses this behaviour. If you think this is is wrong, this > should be generally discussed (e.g. on debian-devel). > You intentionally try to hide facts.
i am not hiding facts, intentionally or otherwise. please confine yourself to discussing the issue rather than making irrelevant personal attacks. i assure you that you do not want me to start making personal attacks on you. i will be much better at that than you are if i choose to go down that route. and while you're at it, stop being so defensive. this is about a bug in your package. it's not about you personally. > > 2. yes, i had the same initial thought, of doing a simple grep to find > > packages which stop the daemon in the prerm script. > > > > but, as is obvious from a little bit more thought about it, a simple > > grep won't tell you whether the stop command is wrapped inside an > > if/then or case statement, will it? so it tells you nothing useful. > > > > Sure, I quickly glanced over the packages, and only openssh seems to run > stop only during remove/deconfigure. > This makes 77:1 there's also postfix, which i've mentioned before. and apache. and most of the following: $ grep -l 'stop' /var/lib/dpkg/info/*.prerm | xargs grep -l 'remove' /var/lib/dpkg/info/acct.prerm /var/lib/dpkg/info/apache2-mpm-itk.prerm /var/lib/dpkg/info/autofs.prerm /var/lib/dpkg/info/console-common.prerm /var/lib/dpkg/info/console-tools.prerm /var/lib/dpkg/info/cpufrequtils.prerm /var/lib/dpkg/info/cupsys.prerm /var/lib/dpkg/info/debtorrent.prerm /var/lib/dpkg/info/ebtables.prerm /var/lib/dpkg/info/gdm.prerm /var/lib/dpkg/info/gom.prerm /var/lib/dpkg/info/gpm.prerm /var/lib/dpkg/info/john.prerm /var/lib/dpkg/info/kdm.prerm /var/lib/dpkg/info/lirc.prerm /var/lib/dpkg/info/lm-sensors.prerm /var/lib/dpkg/info/locate.prerm /var/lib/dpkg/info/mgetty-fax.prerm /var/lib/dpkg/info/mpd.prerm /var/lib/dpkg/info/mt-st.prerm /var/lib/dpkg/info/nfs-common.prerm /var/lib/dpkg/info/nfs-kernel-server.prerm /var/lib/dpkg/info/nut.prerm /var/lib/dpkg/info/nvidia-glx.prerm /var/lib/dpkg/info/nvi.prerm /var/lib/dpkg/info/openssh-server.prerm /var/lib/dpkg/info/postfix.prerm /var/lib/dpkg/info/postgresql-8.3.prerm /var/lib/dpkg/info/ppp.prerm /var/lib/dpkg/info/procps.prerm /var/lib/dpkg/info/quota.prerm /var/lib/dpkg/info/rplay-server.prerm /var/lib/dpkg/info/rsync.prerm /var/lib/dpkg/info/shorewall-doc.prerm /var/lib/dpkg/info/slashem-common.prerm /var/lib/dpkg/info/spamassassin.prerm /var/lib/dpkg/info/squid.prerm /var/lib/dpkg/info/stunnel4.prerm /var/lib/dpkg/info/tdsodbc.prerm /var/lib/dpkg/info/twm.prerm /var/lib/dpkg/info/udev.prerm /var/lib/dpkg/info/uucp.prerm /var/lib/dpkg/info/vdr.prerm /var/lib/dpkg/info/vtun.prerm /var/lib/dpkg/info/xcursor-themes.prerm /var/lib/dpkg/info/xserver-xorg.prerm /var/lib/dpkg/info/zaptel.prerm gdm and xserver-xorg are particular obvious cases. blindly running stop in the prerm would kill the xterm (or GUI apt-get wrapper) that the upgrade is being run from, while the upgrade is in progress. this is self-evidently WRONG behaviour. similarly, stopping rsyslog during an upgrade is also self-evidently wrong behaviour. ppp is another obvious case. stopping ppp during an upgrade of a remote system could kill the connection and thus the ssh session that the upgrade is being performed on, during the upgrade - leaving no way to get back in to complete the upgrade. that's self-evidently wrong. ditto for openssh-server. in fact, i recall deliberately installing telnetd-ssl (and configuring it to only allow encrypted connections. and tcp-wrappers was configured to only allow connections from known, trusted hosts) on systems until the problem with the ssh package as it was called back then was fixed just so that i had an alternate way to log in and complete the upgrade. a habit i retained for many years afterwards - i only stopped routinely installing and configuring telnetd-ssl a few years ago, and i still install it on systems where it is vital that i be able to login remotely in case of emergency. > Please show me your numbers. it's not about numbers. it's about correct behaviour. it doesn't matter if 10,000 other packages are doing the wrong thing - it's STILL the wrong thing, it's still a bug, and it still should be fixed. correct behaviour is to minimise downtime during an upgrade. corect behaviour is to NOT lose important, irreplaceable data. FYI, of the 122 prerm scripts on my system that contain the text 'stop', 47 of them also contain the text 'remove', implying that they have special-case code to handle upgrade differently to a remove or purge. a cursory examination of those prerm scripts shows that that is the case for most of them. there are a few that i noticed where the package maintainer checks for 'upgrade' but treats it the same as 'remove' - that's either a bug or the maintainer had a particular good reason for doing that. i don't know and i don't care to either examine further or file bug-reports until and unless it causes me a problem. rsyslog (and bind9) have caused me problems so far with this behaviour, so i have filed bugs against both of them (and against debhelper too). $ grep -l 'stop' /var/lib/dpkg/info/*.prerm | wc -l 122 $ grep -l 'stop' /var/lib/dpkg/info/*.prerm | xargs grep -l 'remove' | wc -l 47 > You say, that you have been DD oh so long (which is irrelevant to this > discussion btw), and you claim your point of view is the intended > behaviour. Numbers are not on your side and there is no passage in the > policy or devref which backs your claims. > > Show some authorative discussion etc. and I might change my mind. if you want discussion, search the archives of debian-devel from the mid 90s for problems encountered during ppp and sshd upgrades. this is a problem that has been encountered before, debated before, solved before, and now enough time has passed that newer DDs are repeating the mistakes of the past. ppp doesn't stop during an upgrade, only on remove. same for sshd. examine their prerm files. why the hell do you think that 'upgrade', 'remove', 'purge', and related arguments are passed to the pre/post scripts by dpkg if they're not intended to be used for decision-making within the scripts? they're not an "unmaintainable mess" as you allege. they are documented features intended to be used by package maintainers so that the maintainers can do the right thing with their packages. that's why there are skeleton scripts showing the outline of what do in in the pre/post scripts. see section 6.5, "Summary of ways maintainer scripts are called" and section 6.6, "Details of unpack phase of installation or upgrade" of the debian policy manual for documentation on how these things work. > > you have to actually examine each script to find out whether it is > > only stopping the daemon on a remove/purge (in which case, running the > > init.d script or invoke-rc.d to stop the daemin is correct behavior), or > > whether it's doing it all the time. in which case, it's broken behaviour > > - see point 1 above. > > see above indeed. see above. > >>> postfix, like MOST other daemon packages i use, also doesn't. postfix's > >> Wrong, most packages use the way I described. > > > > some packages are broken in the way that has been described. > > > > that doesn't make it right. > > > > that just means that there are other broken packages. > > Well, the numbers show, that it is common practice, even for services > like samba, postgresql-8.3, mysql-server-5.0 (which you claimed does it > differently), which to my account also hold important data. and they're broken too, in exactly the same way as your package. being right or wrong is not decided by a vote or a count. wrong is wrong, no matter how many other things are wrong in the same way. (as for mysql-server-5.0, i must have been looking at the postrm script rather than the prerm script and only glanced quickly at it. you are correct - it is also broken). craig -- craig sanders <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
