The following bug report got me thinking:
--------------------------------------------------------------------
Subject: Bug#381107: sawfish update: postinst failure
# apt-cache policy sawfish
sawfish:
  Installiert:1:1.3+cvs20040617-7
  Mögliche Pakete:1:1.3+cvs20060518-3
  Versions-Tabelle:
     1:1.3+cvs20060518-3 0
        990 ftp://ftp.de.debian.org unstable/main Packages
     1:1.3+cvs20060518-2 0
        500 ftp://ftp.de.debian.org testing/main Packages
 *** 1:1.3+cvs20040617-7 0
        100 /var/lib/dpkg/status

dora:/home/agnes# apt-get install sawfish
[...]
install/sawfish: Handling install for emacsen flavor emacs20
Opening input file: no such file or directory, /usr/lib/X11/locale/locale.alias
emacs-package-install: /usr/lib/emacsen-common/packages/install/sawfish
emacs20 emacs20 failed at /usr/lib/emacsen-common/emacs-package-install line 30, <TSORT> line 1.
dpkg: Fehler beim Bearbeiten von sawfish (--configure):
 subprocess post-installation returned error 255
---------------------------------------------------------------------

As far as I can see, the problem is that emacs20 no longer runs with
the updated X that's pulled in by a recent sawfish, and thus it causes
the post-inst script to fail.

My first reaction then is to reassign the bug to emacs20, so it looks
for files in the proper places. But emacs20 was removed 2+ years
ago, sometime between woody and sarge. So now I have the problem of a
non existent but probably widely deployed package that works in sarge
but will block updates to etch, at least for my package.

I could work around this on my post-inst, by exiting if FLAVOUR==emacs20
or something like that, but I smell a wider reaching problem here.

Maybe emacsen-common should not attempt to install packages for old
flavours of emacs, namely (in this case) emacs20 (and most likely
emacs19, but I have no idea).

# Automatically generated email from bts, devscripts version 2.10.11
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 333225 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 375732 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 381516 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 386647 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 397052 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 400420 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 404890 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 418823 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 419144 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 439545 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 440117 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 441326 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 443079 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 443351 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 445466 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 445659 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 447797 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 447829 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 450565 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 453713 rodrigo@debian.org
#Update submitter address to ease tracking. Sorry about the bts noise.
submitter 453778 rodrigo@debian.org

package emacsen-common
tag 117564 +pending +patch
tag 122444 +pending +patch
tag 124221 +pending +patch
tag 132355 +pending +patch
tag 136779 +pending +patch
tag 157123 +pending +patch
tag 193575 +pending +patch
tag 208414 +pending +patch
tag 222518 +pending +patch
tag 269155 +pending +patch
tag 278008 +pending +patch
tag 329030 +pending +patch
tag 361200 +pending +patch
tag 381516 +pending +patch
tag 387021 +pending +patch
tag 424940 +pending +patch
tag 491129 +pending +patch
tag 503483 +pending +patch
thanks

I am tagging all these bugreports +pending +patch, since they will be dealt
with by the NMU I am preparing. I am currently waiting for news on the lenny
release before actually upload, but since is taking longer than expected I
will probably upload really soon.

Changes go much further than an usual NMU, but since I received no reply on
this during some long time I will proceed with it. Changes can be tracked at
the git repo

git://git.debian.org/git/users/agmartin/my-emacsen-common.git

(browseable through
http://git.debian.org/?p=users/agmartin/my-emacsen-common.git;a=summary)

NMU candidate is available at

http://people.debian.org/~agmartin/debian-store/misc/

With emacs20 (and even more so emacs19) still installed, it's very common
for an elisp package to work well with some Emacs flavors but not all.
Byte-compilation is not necessary for packages to work, usually, so
failure to byte-compile a package should simply not be considered as
a failure to install the package.


	Stefan


PS: Of course, all this would be less important if it were easier to tell
APT/DPKG to ignore some script errors.  Currently such errors tend to block
everything, and when they occur in the removal script, it means that the
only way to fix the system is by getting your hands really dirty.

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

At the moment, both with respect to this and the original issue, I'm
inclined to think that it really shouldn't be any of emacsen-common's
business.

i.e. if an add-on package doesn't work with a given older emacs, then
that package should add appropriate guards, and if an add-on package
knows that it's safe to continue even after some part of its
install/remove scripts fail, then it should just make sure that those
scripts exit without an error status when appropriate.

Though I'll think about it a bit more -- perhaps I can convince myself
otherwise.

Thanks

This is not about a package not working with some older Emacs version.

It's about failure of *installation*, more specifically a failure which is
a pain in the rear to circumvent.  In all cases I've ever seen, the
package is still perfectly usable after circumventing this
installation problem.

And even if that package doesn't work with emacs19, who cares?
I should still be able to install it, in case I want to use it with emacs23.
A warning/message about the problem is fine, but an error that prevents
aptitude from doing its job is really mean.


        Stefan

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

Yes, but I don't see how emacsen-common could know that, and as far as I
understand things, a successful exit from a dpkg run is supposed to
indicate that everything's fine.

When an add-on package's script fails, as far as emacsen-common knows,
something terrible might have happened.  But I'll ask around, and see
what other maintainers think.

Thanks

And as a general, rule when Elisp's byte-compilation signals an error,
everything is still fine.


        Stefan

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

But even if Emacs guarantees that, we still have to have some way for
emacsen-common to know that's the situation.

And I suppose I'm still inclined to argue that the responsibility may
lie with the add-on package scripts, i.e. they should arrange to return
0 in that case -- but as mentioned, I'll ask around.

Thanks

Emacs doesn't guarantee anything.  But we know that's the situation
because it always is.


        Stfean

To the extent that neither aptitude nor dpkg offers a way for the user
to use something like a --force flag to ignore the problems, signaling
an error there should be limited to the utmost terrible cases where the
world is about to end.

Even in the very unlikely case that the package is somehow faulty,
I *much* prefer being able to install it, discover that it's faulty and
then remove it, then being left in the dark and told "sorry, we're not
100% sure that it will always work, so you can't even try using it".
Especially since the "100% sure" is not even true.  There can be plenty
of other errors which don't prevent installation but prevent use.

I used the word "mean" before to describe the behavior, but the word
I wanted to use was "obnoxious".


        Stefan

Dear Customer,

We could not deliver your parcel.
Delivery Label is attached to this email.

Yours sincerely,
Joel Buchanan,
Sr. Station Manager.

Dear Customer,

Your parcel has arrived at October 12. Courier was unable to deliver the parcel to you.
Shipment Label is attached to this email.

Regards,
Isaac Jordan,
Sr. Operation Manager.

Dear Customer,

Courier was unable to deliver the parcel to you.
Shipment Label is attached to this email.

Kind regards,
Tony Young,
Sr. Delivery Manager.

Dear Customer,

We could not deliver your parcel.
Delivery Label is attached to this email.

Yours sincerely,
Robert Haas,
Support Manager.

Dear Customer,

This is to confirm that one or more of your parcels has been shipped.
Delivery Label is attached to this email.

Yours faithfully,
Glenn Driscoll,
FedEx Support Manager.

Dear Customer,

Courier was unable to deliver the parcel to you.
Please, download Delivery Label attached to this email.

Regards,
Dean Baird,
FedEx Operation Manager.

Dear Customer,

Your parcel has arrived at October 15. Courier was unable to deliver the parcel to you.
Please, download Delivery Label attached to this email.

Thank you for choosing FedEx,
Karl Post,
Sr. Station Manager.

dzień dobry

Nazywam się George Mike. Z zawodu jestem prawnikiem. Chcę ci zaoferować
najbliższy krewny mojego klienta. Odziedziczysz sumę (8,5 miliona dolarów)
dolarów, które mój klient zostawił w banku przed śmiercią.

Mój klient jest obywatelem twojego kraju, który zginął wraz z żoną w
wypadku samochodowym
i jedyny syn. Będę uprawniony do 50% całkowitego funduszu, podczas gdy
50% będzie
Być dla ciebie.
Aby uzyskać więcej informacji, skontaktuj się z moim prywatnym adresem
e-mail: georgemike7031@gmail.co

Z góry bardzo dziękuję,
Panie George Mike,