Comment 7 for bug 456523

On Thu, 8 Jan 2004, Rob Browning wrote:

> Santiago Vila <email address hidden> writes:
>
> >> This should be closed then, since it looks like the gettext bug has
> >> also been fixed.
> >
> > Please don't. Failing to work just because a missing dependency when
> > it is *perfectly* possible for emacsen-common to deal with this is
> > wrong.
>
> It seems like a reasonable counter-argument to claim that packages
> shouldn't be expected to work around missing package dependencies in
> their install scripts, even if it's possible, and that it's the
> responsibility of the package to get its dependencies right.

I mostly agree with that, but only as a general rule. In this case the
dependency is not the typical shared library dependency, it's just a
dependency to make sure emacsen-common.postinst is executed at least
once before emacs-package-install is executed for the first time.

Now let's analyze: What does emacsen-common.postinst really do?
It does several things, but it basically creates the file
/var/lib/emacsen-common/installed-flavors as an empty file
if it does not exist. This is a trivial task which could well
be done by emacs-package-install, it's not such a complex task.

My point is that failing to create an empty file, which is a rather
trivial task, should not make an entire upgrade to fail.

People expect upgrades to be smooth. I of course agree that packages
not following emacs policy deserve a bug and they should be fixed, but
in the hypothetical case that we release sarge with packages not
following emacs policy, many upgrades will fail miserably, causing
trouble to lots of people, this could be avoided easily by
emacsen-common being a little bit fault-tolerant, I'm not talking
about doing weird things, it's just a matter of creating a single
file if it does not exist.

> Breaking the install just highlights the problem, and probably makes
> sure the package won't get into testing or stable until it's fixed.

But that's not a proportionate effect for not creating a single file
which emacs-package-install could create trivially.

As for "highlighting the problem", I have already suggested that you
stop the upgrade while the warning message is shown to the user.
If you stop the upgrade and ask the user to report it as a serious
bug and then press enter, it is almost sure that bugs will be filled,
but even if it's not and we release sarge with packages having this bug,
upgrading from woody to sarge will not be a nightmare.

If by accident we release sarge with packages not following emacs policy,
there will be no point in making upgrades to fail "so that bugs are
reported", because these bugs will never be fixed in sarge, the will
only be fixed in unstable.

For this reason I think the lack of fault-tolerance is disproportionate.
It's just a matter of creating a single file.