#include <hallo.h>
* Samuel Mimram [Thu, Jul 20 2006, 01:04:53AM]:
> Eduard Bloch wrote:
> > #include <hallo.h>
>
> #include <bonjour.h>
>
> > * Samuel Mimram [Thu, Jul 20 2006, 12:26:40AM]:
> >> Eduard Bloch wrote:
> >>> Package: mldonkey-server
> >>> Version: 2.7.3-2
> >>> Severity: grave
> >>>
> >>> (Reading database ... 147973 files and directories currently installed.)
> >>> Preparing to replace mldonkey-server 2.7.3-2 (using
> >>> .../mldonkey-server_2.7.7-4_amd64.deb) ...
> >>> Stopping MLDonkey: mlnetNo process in pidfile
> >>> `/var/run/mldonkey/mlnet.pid' found running; none killed.
> >>> invoke-rc.d: initscript mldonkey-server, action "stop" failed.
> >>> dpkg: warning - old pre-removal script returned error exit status 1
> >>> dpkg - trying script from the new package instead ...
> >>> Stopping MLDonkey: mlnetNo process in pidfile
> >>> `/var/run/mldonkey/mlnet.pid' found running; none killed.
> >>> invoke-rc.d: initscript mldonkey-server, action "stop" failed.
> >>> dpkg: error processing
> >>> /var/cache/apt/archives/mldonkey-server_2.7.7-4_amd64.deb (--unpack):
> >>> subprocess new pre-removal script returned error exit status 1
> >>> Starting MLDonkey: mlnet configuration file prevent mlnet to be started
> >>> (use force-start).
> >>> Errors were encountered while processing:
> >>> /var/cache/apt/archives/mldonkey-server_2.7.7-4_amd64.deb
> >>> E: Sub-process /usr/bin/dpkg returned an error code (1)
> >> Unfortunately, this was a bug in the 2.7.3-2 version of the package
> >> (which was removed from testing), see #338875, #363635 and #368118.
> >
> > I don't talk about testing. And the log message says the bug exists in
> > the new version as well ("using .../mldonkey-server_2.7.7-4_amd64.deb"
> > "dpkg - trying script from the new package instead ...").
>
> The stop) action of the new script is fairly simple:
>
> stop)
> echo -n "Stopping $DESC: $NAME"
> start-stop-daemon --stop --oknodo --pidfile $PIDFILE
> echo "."
> ;;
>
> Let's try a little experiment (of course the "toto" file does not exist):
Well, that is not the point! When the new version of prerm is run, it
does still execute the _old_ init script. So, how do you intend to solve
this problem?
Removing a package from testing (btw, packages.d.o still says it is
there) does not automaticaly disable all such time bombs outthere.
If I were you, I would stop using dh_installinit and make the prerm
failure-resistant with custom code.
And I wish dh_installinit would have an option for
not-failing-on-restart-problems.
Eduard.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
