Distribution Upgrade to karmic freezes on gtk-doc-tools

reassign 153860 emacsen-common
thanks

Note for the emacsen-common maintainer:

I ALREADY know that gettext-el in woody does not depend on emacsen.
This was a required compromise for the gettext/gettext-el split.

gettext_0.10.40-7 already depends on emacsen, I don't need you to make
a crusade against gettext-el, thanks, so please make emacsen-common
more robust. Giving an error just make everybody to waste time
and does not help anybody.

> Package: gettext-el
> Version: 0.10.40-6
> Severity: important
>
> whilst performing my daily apt-get upgrade.. (can reproduced this on two machines):
>
> grumble:~# apt-get upgrade
> Reading Package Lists... Done
> Building Dependency Tree... Done
> 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 18 packages not fully installed or removed.
> Need to get 0B/41.9kB of archives. After unpacking 0B will be used.
> Do you want to continue? [Y/n]
emacsen-common> (Reading database ... 34443 files and directories currently installed.)
> Preparing to replace gettext-el 0.10.40-6 (using
> .../gettext-el_0.10.40-7_all.deb) ...
> ERROR: emacsen-common being used before being configured.
> ERROR: This is likely a bug in the gettext-el package, which needs to
> ERROR: add one of the appropriate dependencies.
> ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz
> ERROR: for details.
> dpkg: warning - old pre-removal script returned error exit status 2
> dpkg - trying script from the new package instead ...
> ERROR: emacsen-common being used before being configured.
> ERROR: This is likely a bug in the gettext-el package, which needs to
> ERROR: add one of the appropriate dependencies.
> ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz
> ERROR: for details.
> dpkg: error processing
> /var/cache/apt/archives/gettext-el_0.10.40-7_all.deb (--unpack):
> subprocess new pre-removal script returned error exit status 2
> ERROR: emacsen-common being used before being configured.
> ERROR: This is likely a bug in the gettext-el package, which needs to
> ERROR: add one of the appropriate dependencies.
> ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz
> ERROR: for details.
> dpkg: error while cleaning up:
> subprocess post-installation script returned error exit status 2
> Errors were encountered while processing:
> /var/cache/apt/archives/gettext-el_0.10.40-7_all.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> grumble:~#

severity 153860 serious
thanks

Hi.. I've experienced this problem as well, this time with the sawfish
package.

I did a full upgrade today, which included an upgrade of sawfish and a
new install of emacsen-common. As a result:

  Preparing to replace sawfish 1:1.3+cvs20031104-2 (using
    .../sawfish_1%3a1.3+cvs20031104-3_i386.deb) ...
  ERROR: emacsen-common being used before being configured.
  ERROR: This is likely a bug in the sawfish package, which needs to
  ERROR: add one of the appropriate dependencies.
  ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz
  ERROR: for details.
  dpkg: warning - old pre-removal script returned error exit status 2
  dpkg - trying script from the new package instead ...
  ERROR: emacsen-common being used before being configured.
  ERROR: This is likely a bug in the sawfish package, which needs to
  ERROR: add one of the appropriate dependencies.
  ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz
  ERROR: for details.
  dpkg: error processing
  /var/cache/apt/archives/sawfish_1%3a1.3+cvs20031104-3_i386.deb
  (--unpack):
   subprocess new pre-removal script returned error exit status 2

I presume the error was generated by the prerm for the old sawfish,
which calls emacs-package-remove. At this stage emacsen-common has been
unpacked but not configured.

I'm marking this as serious since it causes packages to fail to
configure. If it's a sawfish problem, feel free to reassign it - I'm
not particularly familiar with emacs policy. However, if emacsen-common
requires itself to be configured before use then it seems that packages
such as gettext-el and sawfish should pre-depend on emacsen-common,
which is certainly not mentioned in emacs policy.

CCing the sawfish maintainer also.

Thanks - Ben. :)

reassign 153860 sawfish
thanks

This bug looks like it was fixed in gettext-el, but the latest
addition to the bug report suggests that sawfish has the same problem
(i.e. calls emacsen-common code without arranging the dependencies as
per /usr/share/doc/emacsen-common/debian-emacs-policy.gz), so I'm
reassigning this bug to sawfish.

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

This should be closed then, since it looks like the gettext bug has
also been fixed.

Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

reassign 153860 gettext-el
thanks

<email address hidden> (Debian Bug Tracking System) writes:

> Processing commands for <email address hidden>:
>
>> reassign 153860 sawfish
> Bug#153860: gettext-el: apt-get update. dpkg: error processing /var/cache/apt/archives/gettext-el_0.10.40-7_all.deb (--unpack)
> Bug reassigned from package `emacsen-common' to `sawfish'.

Thanks for the Cc: ...

> This bug looks like it was fixed in gettext-el, but the latest
> addition to the bug report suggests that sawfish has the same problem
> (i.e. calls emacsen-common code without arranging the dependencies as
> per /usr/share/doc/emacsen-common/debian-emacs-policy.gz), so I'm
> reassigning this bug to sawfish.

Sorry but no, sawfish don't need to byte-compile sawfish.el and thus
don't need to depends on emacsen-common.

Also this bug report display gettext error messages and nothing is
related to sawfish.

Christian

reassign 153860 emacsen-common
retitle 153860 emacsen-common SHOULD be more robust
severity 153860 important
thanks

Christian Marillat wrote:

> Processing commands for <email address hidden>:
>
> > reassign 153860 gettext-el
> Bug#153860: gettext-el: apt-get update. dpkg: error processing /var/cache/apt/archives/gettext-el_0.10.40-7_all.deb (--unpack)
> Bug reassigned from package `sawfish' to `gettext-el'.

This bug was fixed in gettext_0.10.40-8 as shown by the changelog:

  * Made gettext-el prerm and postinst fault-tolerant, since emacsen-common
    is not. Should allow upgrades from woody.

I reiterate that emacsen-common needs to be more robust. Failing to
work just because a missing dependency WHEN IT IS PERFECTLY POSSIBLE
for emacsen-common to deal with this is just WRONG.

There is NOTHING vitally important in emacsen-common.postinst which may
not be done in /usr/lib/emacsen-common/emacs-package-install AS WELL
the first time it's used.

Reassigning again, since emacsen-common has not changed at all since
woody was released.

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.

Santiago Vila <email address hidden> writes:

> 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.

But it also makes the guarantee that if a postinst succeeds, then
emacsen-common (and whatever packages are properly configured using
it) are properly installed and ready to go.

What I'm vaguely concerned about is setting emacsen-common up in any
way that can make it look like everything's OK, when in fact say gnus
(for example), is now misconfigured (or partially configured) in some
way that can lose mail. I'm not *sure* this is critical, but I'm not
sure it's not either, and hence my hesitation. I'm also wondering
about how this problem might be amplified by broken emacsen-packages
that other emacsen packages depend on (i.e. if gnus depends on
mail-foo-el, and mail-foo-el doesn't get set up right).

Causing the install to fail at least guarantees that it will be
obvious that something's wrong, and may prevent compounding the
problem by proceeding anyway.

I suppose one possibility might be to change the error to say
something like "It looks like this package is using the emacs
infrastructure improperly, please report this as a bug, and, as a
temporary fix, you should probably be able to just remove this package
and then resume your install/upgrade." Would that address any of your
concerns, or would it still be too severe?

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

To me it's not "creating the single file" that's my main concern, it's
the semantic implications of exiting without an error code when
emacsen-common knows something has gone wrong.

Don't get me wrong, I'm not convinced either way yet, but I need to
think it over a bit more before I could comfortably decide to change
the behavior. I'll think about it a bit, and perhaps ask on
debian-emacsen.

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

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. Breaking
the install just highlights the problem, and probably makes sure the
package won't get into testing or stable until it's fixed.

I'll have to think about it, but at the moment I'm still inclined
toward closing this.

In any case, I appreciate the discussion, and sorry that bug got
reassigned to you *again*.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

reopen 153860
originator 153860 <email address hidden>
thanks

On Wed, 7 Jan 2004, Rob Browning wrote:

> 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.

Please change the ERROR messages into a WARNING and modify
emacs-package-install so that it does whatever it's required to
initialize the database. Pause the upgrade until the user press Enter
if you like, so that the user has time to write down the message and
report it as a bug, tell the user to submit a serious bug if you like,
but Debian is known (and we aim) to be *robust*. The fact that
emacsen-common makes the upgrade to fail when there is not a real and
absolute need damages the reputation of Debian being robust.

submitter 153860 <email address hidden>
thanks

Sorry, it was "submitter", not "originator".

Package: emacsen-common
Version: 1.4.15
Followup-For: Bug #153860

This bug has been biting for looks like a couple of years. I think it's
high time to stomp it, yes? It hasn't gone away -- because the postinst
script at: /var/lib/dpkg/info/emacsen-common.postinst doesn't appear to
have been fixed, AFAIK.

There are at least TWO places it actually fails -- and not gracefully.
Right at the top:

 ##!/bin/sh
 #
 #set -e
 #
 #if [ "$1" = "configure" ]
 #then
 # if [ -d /usr/doc \
 # -a ! -e /usr/doc/emacsen-common \
 # -a -d /usr/share/doc/emacsen-common ]
 # then
 # ln -sf ../share/doc/emacsen-common /usr/doc/emacsen-common
 # fi
 #fi

If I'm not mistaken, this code fails because:
 # ln -sf ../share/doc/emacsen-common /usr/doc/emacsen-common
fails -- since the operation is not carried-out inside /usr/doc.
And it, of course, causes all depending package installs to fail too.
(This bug is just "important", right? Not 'grave'..?)

I fixed it by running:
 # ln -sf ../share/doc/emacsen-common /usr/doc/emacsen-common
myself.

The script also bails out (for me, anyway) at your favorite spot:

 #if [ ! -e /var/lib/emacsen-common/installed-flavors ]
 #then
 # # Be super-careful.
 # echo -n "" > /var/lib/emacsen-common/installed-flavors
 # chmod 644 /var/lib/emacsen-common/installed-flavors
 # echo -n "" > /var/lib/emacsen-common/installed-flavors
 #fi

I note that /var/lib/emacsen-common/ itself didn't exist on my
system -- and that is enough for the script to fail AFAIC see.
This problem went away(?) after I just created /var/lib/emacsen-common/
and THEN touched /var/lib/emacsen-common/installed-flavors.

All in all I'd say that having this buggy script hanging around for
2+(?) years causing problems is reason to be asking a few questions
beyond the technical.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (998, 'testing'), (99, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.20
Locale: LANG=en_US, LC_CTYPE=en_US

Versions of packages emacsen-common depends on:
ii bsdmainutils 6.0.15 collection of more utilities from

-- no debconf information

"Jim W. Jaszewski" <email address hidden> writes:

> If I'm not mistaken, this code fails because:
> # ln -sf ../share/doc/emacsen-common /usr/doc/emacsen-common
> fails -- since the operation is not carried-out inside /usr/doc.

Agreed, that's probably wrong. I'll try to have a fix out shortly.

> The script also bails out (for me, anyway) at your favorite spot:
>
> #if [ ! -e /var/lib/emacsen-common/installed-flavors ]
> #then
> # # Be super-careful.
> # echo -n "" > /var/lib/emacsen-common/installed-flavors
> # chmod 644 /var/lib/emacsen-common/installed-flavors
> # echo -n "" > /var/lib/emacsen-common/installed-flavors
> #fi
>
> I note that /var/lib/emacsen-common/ itself didn't exist on my
> system

Hmm, I'm not sure how it couldn't exist since it's in the
emacsen-common package, and this script is the postinst.

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4