>>>>> "Simon" == Simon McVittie <smcv@debian.org> writes:
Simon> the error path is most important were packages that provide a
Simon> system-level API to other packages, so their failures are
Simon> likely to cause other packages to fail to configure (such as
Simon> local DNS caches and authentication services like LDAP); and
Simon> packages that provide remote access, so their failures need
Simon> to be fixed before a potentially remote sysadmin logs out to
Simon> prevent the sysadmin from being locked out longer-term (like
Simon> sshd).
As a maintainer of one of the more important packages (krb5-kdc and
krb5-admin-server), ;I'd like to chime in here. krb5-kdc provides
enterprise level authentication and if it fails may well take out
authentication for an entire environment.
Even so, I've found that causing upgrades to fail does far more harm
than good even for this package.
Here is my experience based on my own observations and based on bug
reports and helping people diagnose problems in krb5:
* The vast majority of failures are when krb5-kdc gets installed on a
system where it is not actually needed, or where it was partially
configured for a test. In these cases, breaking an kupgrade does
much more harm than good. It may break other services, because those
services may end up in a half-configured state, so a service that is
not critical for a given system may break critical services for that
system.
* When krb5 is a critical service, it's failure is going to be quite
obvious regardless of whatever the maint script does.
* It is almost always the case that debugging the situation involves
installing some package and that the first thing I end up doing is
walking a user through adding exit 0 at the top of postinst in
/var/lib/dpkg/info before going forward. Even if I don't need some
additional tool, I've been burned by other parts of the system being
in half-configured state.
* Leaving large chunks of the system in half-configured states is about
one of the worst things you can do for system stability. It's not
something we test very often, and the interactions are very difficult
to predict.
If I understood the cause of an error in a maintainer script and knew
that it indicated a problem that the sysadmin needed to fix (and one
that likely indicated krb5 was important on this system) I would be open
to returning a failure in postinst.
In almost all other situations I'd rather simply let the service fail to
start.
Attachment:
signature.asc
Description: PGP signature