help-shishi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian shishi package bug


From: Simon Josefsson
Subject: Re: Debian shishi package bug
Date: Sat, 22 Apr 2006 11:18:22 +0200
User-agent: Gnus/5.110005 (No Gnus v0.5) Emacs/22.0.50 (gnu/linux)

Russ Allbery <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>
>> It seems there is a bug in the IPv6 listening code, listening to socket
>> 0 sounds like listening on stdin, which would explain the Ctrl-D thing.
>> I'll look into this.
>
>> I think shishid should not start by default.  Users should enable it
>> manually so they are sure they know what they are doing.  When shishid
>> is more widely tested, we can revert this behaviour.
>
> Okay, I'm going to add an /etc/default/shishid file that sets a variable
> saying not to start the daemon by default and that users can change to
> enable automated starting.

Sounds good.

>>> Also, if shishid isn't running, the init script stop action fails
>
>> That sounds bad -- IMHO, the stop action shouldn't fail because the
>> process had already died.
>
>> Should we fix the init script here?
>
> Yes.  --oknodo is needed; I'll add it.

Ah, I didn't know about --oknodo.  It seems appropriate.

>> I used the template init script from some Debian manual, so if there is
>> a problem in it, perhaps we should forward this.
>
> Yeah, I'm pondering that.  I can see cases where this is desirable (if,
> for instance, failure to cleanly stop a daemon before upgrading would
> result in data loss); we just don't happen to have any of those cases.

With --background and --oknodo being available, I'm less sure there is
a problem in the example, it is just an example.

>>> which then causes all sorts of strange problems for the upgrade
>>> process.  In fact, if the old shishid package is installed, it appears
>>> to be impossible to upgrade the system; the package is so broken that
>>> there doesn't appear to be any way to get rid of it without manually
>>> removing the init script and then using dpkg --purge
>>> --force-remove-reinstreq.  I think some of this may be due to a
>>> debhelper bug; I'm investigating.
>
>> Yikes, that's really bad.
>
>> Disabling shishid by default might fix similar problems in the future.
>
>> Removing the init script and invoking the dpkg command works here, so
>> maybe this should go into the changelog?  If we can't find a cleaner
>> upgrade path, that is.
>
> With the help of the debhelper maintainer I have a fix that should work
> and will be committing to CVS shortly.

Great!

/Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]