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

Re: sanity check in init.d



> This looks obvious to you, but dselect only does a --remove, not a
> purge. So if you take a look at init.d/ after two months, it may be
> difficult to say which script acually does something and which is a
> leftover conffile. 

Actually you can make dselect do a purge by use the '_' (underscore)
key instead of the '-' (dash,minus) key. I understand that this is not
obvious.

> The best solution would be to move them to init.d/inactive, but this
> is not possible due to technical reasons.

Not really. Yes, it would be a bad idea for dpkg to special case init.d
stuff, but I suspect that it wouldn't be that hard to modify dpkg to
move *all* "leftover" conffiles to /var/dpkg/confold/original/location/
(e.g. /var/dpkg/confold/etc/init.d/somedaemon) when a package is removed
and not purged, and to look in there for old conffiles when it is
reinstalled. That's actually a good idea.

> SG> Logging *incorrect* failure messages is worse than useless.
> 
> If there is a test for "only conffiles left" possible, it is
> preferred. The message only incorrect, if you fumble with the daemon
> binary.  

The problem is that if I boot a system, and I get a bunch of messages
that look like "ERROR: Startup of somedaemon failed because somedaemon
binary not found", I'm going to waste a lot of time figuring out that
it's because I hit "-" in dselect instead of "_". Actually, I tend not
to purge when I initially remove something, because I might want it
back. Error messages should alert non-normal conditions. The existence
of a leftover config file is not a non-normal condition.

> Yes, the error message would be wrong, so let's think about a way to
> do it better.

The *right* way to do it is for the config file to actually check for
the installation state of the package (which is what the crude "[ -x
/path/to/binary ]" is attempting to check. Unfortunately, at present
dpkg is impossibly slow for that purpose. It may be that one of the
various configuration management projects will solve this, by removing
the need for init.d scripts to be conffiles.

Steve


Reply to: