Debian Bug report logs - #671711
dpkg: runs trigger processing even if depedencies are not satisfied

version graph

Package: dpkg; Maintainer for dpkg is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg is src:dpkg.

Reported by: Andreas Beckmann <anbe@debian.org>

Date: Sun, 6 May 2012 08:39:01 UTC

Severity: important

Merged with 678848, 701047

Found in version dpkg/1.14.17

Blocking fix for 680626: Squeeze->Wheezy: dist-upgrade fails, /usr/bin/python unable to load libssl.so.1.0.0

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Mono Group <pkg-mono-group@lists.alioth.debian.org>:
Bug#671711; Package monodoc-browser. (Sun, 06 May 2012 08:39:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Beckmann <debian@abeckmann.de>:
New Bug report received and forwarded. Copy sent to Debian Mono Group <pkg-mono-group@lists.alioth.debian.org>. (Sun, 06 May 2012 08:39:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Andreas Beckmann <debian@abeckmann.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: monodoc-browser: fails to upgrade from 'testing'
Date: Sun, 06 May 2012 10:37:53 +0200
[Message part 1 (text/plain, inline)]
Package: monodoc-browser
Version: 2.10-3
Severity: serious
User: debian-qa@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails.

>From the attached log (scroll to the bottom...):

  Preparing to replace monodoc-clutter-manual 1.0.0~alpha3~git20090817.r1.349dba6-7 (using .../monodoc-clutter-manual_1.0.0~alpha3~git20090817.r1.349dba6-8_all.deb) ...
  Unpacking replacement monodoc-clutter-manual ...
  Processing triggers for monodoc-browser ...
  generating monodoc search index...
  grep: /etc/gre.d/*.conf: No such file or directory
  
  Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f' or one of its dependencies.
  File name: 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f'
  [ERROR] FATAL UNHANDLED EXCEPTION: System.IO.FileNotFoundException: Could not load file or assembly 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f' or one of its dependencies.
  File name: 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f'
  dpkg: error processing monodoc-browser (--unpack):
   subprocess installed post-installation script returned error exit status 1
  configured to not write apport reports
  Errors were encountered while processing:
   monodoc-browser


cheers,

Andreas
[monodoc-clutter-manual_1.0.0~alpha3~git20090817.r1.349dba6-8.log.gz (application/x-gzip, attachment)]

Added indication that 671711 affects monodoc-clutter-manual Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Wed, 09 May 2012 14:15:16 GMT) Full text and rfc822 format available.

Marked as found in versions monodoc-clutter-manual/1.0.0~alpha3~git20090817.r1.349dba6-8. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Wed, 09 May 2012 14:15:17 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Mono Group <pkg-mono-group@lists.alioth.debian.org>:
Bug#671711; Package monodoc-browser. (Wed, 09 May 2012 15:15:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Iain Lane <laney@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Mono Group <pkg-mono-group@lists.alioth.debian.org>. (Wed, 09 May 2012 15:15:07 GMT) Full text and rfc822 format available.

Message #14 received at 671711@bugs.debian.org (full text, mbox):

From: Iain Lane <laney@debian.org>
To: Andreas Beckmann <debian@abeckmann.de>, 671711@bugs.debian.org
Cc: debian-dpkg@lists.debian.org
Subject: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
Date: Wed, 9 May 2012 16:12:14 +0100
[Message part 1 (text/plain, inline)]
Greetings,

[ @ debian-dpkg, there is a question for you below ]

Thanks for the report.

On Sun, May 06, 2012 at 10:37:53AM +0200, Andreas Beckmann wrote:
> […]
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails.
> 
> >From the attached log (scroll to the bottom...):
> 
>   Preparing to replace monodoc-clutter-manual 1.0.0~alpha3~git20090817.r1.349dba6-7 (using .../monodoc-clutter-manual_1.0.0~alpha3~git20090817.r1.349dba6-8_all.deb) ...
>   Unpacking replacement monodoc-clutter-manual ...
>   Processing triggers for monodoc-browser ...
>   generating monodoc search index...
>   grep: /etc/gre.d/*.conf: No such file or directory
>   
>   Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f' or one of its dependencies.
>   File name: 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f'
>   [ERROR] FATAL UNHANDLED EXCEPTION: System.IO.FileNotFoundException: Could not load file or assembly 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f' or one of its dependencies.
>   File name: 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f'
>   dpkg: error processing monodoc-browser (--unpack):
>    subprocess installed post-installation script returned error exit status 1
>   configured to not write apport reports
>   Errors were encountered while processing:
>    monodoc-browser

It's because libgtk2.0-cil (on which monodoc-browser depends) has been
unpacked but not configured at this point. I thought (from reading
/usr/share/doc/dpkg-dev/triggers.txt.gz):

,----
| Packages in t-awaited and t-pending demand satisfaction of their
| dependencies just like packages in installed.
`----

that I could assume this would be the case when running the trigger, but
apparently not. What am I guaranteed here? I spoke to Colin Watson about
this yesterday and he suggested that perhaps the postinst trigger could
register gtk-sharp into the GAC itself, which would be somewhat
unfortunate but would probably work if it is guaranteed that
libgtk2.0-cil will be unpacked or better when the trigger is activated.

In general, what assumptions is it valid to make about the state of
depended-on packages of a package in t-pending when the trigger is
finally processed?

Cheers,

-- 
Iain Lane                                  [ iain@orangesquash.org.uk ]
Debian Developer                                   [ laney@debian.org ]
Ubuntu Developer                                   [ laney@ubuntu.com ]
PhD student                                       [ ial@cs.nott.ac.uk ]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Mono Group <pkg-mono-group@lists.alioth.debian.org>:
Bug#671711; Package monodoc-browser. (Fri, 25 May 2012 07:33:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Iain Lane <laney@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Mono Group <pkg-mono-group@lists.alioth.debian.org>. (Fri, 25 May 2012 07:33:06 GMT) Full text and rfc822 format available.

Message #19 received at 671711@bugs.debian.org (full text, mbox):

From: Iain Lane <laney@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 671711@bugs.debian.org
Subject: Re: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
Date: Fri, 25 May 2012 08:30:28 +0100
[Message part 1 (text/plain, inline)]
reassign 671711 dpkg
affects 671711 src:monodoc-browser
thanks

Hi,

Reassigning to dpkg per Ian and full-quoting for context in the bug.

On Wed, May 23, 2012 at 02:05:12PM +0100, Ian Jackson wrote:
> Iain Lane writes ("Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'"):
> > On Sun, May 06, 2012 at 10:37:53AM +0200, Andreas Beckmann wrote:
> > > […]
> > > Hi,
> > > 
> > > during a test with piuparts I noticed your package fails to upgrade from
> > > 'testing'.
> > > It installed fine in 'testing', then the upgrade to 'sid' fails.
> > > 
> > > >From the attached log (scroll to the bottom...):
> > > 
> > >   Preparing to replace monodoc-clutter-manual 1.0.0~alpha3~git20090817.r1.349dba6-7 (using .../monodoc-clutter-manual_1.0.0~alpha3~git20090817.r1.349dba6-8_all.deb) ...
> > >   Unpacking replacement monodoc-clutter-manual ...
> > >   Processing triggers for monodoc-browser ...
> > >   generating monodoc search index...
> > >   grep: /etc/gre.d/*.conf: No such file or directory
> > >   
> > >   Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f' or one of its dependencies.
> ...
> > >   dpkg: error processing monodoc-browser (--unpack):
> > >    subprocess installed post-installation script returned error exit status 1
> ...
> > It's because libgtk2.0-cil (on which monodoc-browser depends) has been
> > unpacked but not configured at this point. I thought (from reading
> > /usr/share/doc/dpkg-dev/triggers.txt.gz):
> 
> I think this is a bug.
> 
> > ,----
> > | Packages in t-awaited and t-pending demand satisfaction of their
> > | dependencies just like packages in installed.
> > `----
> 
> This is true, but doesn't help you.  The unpack of libgtk2.0-cil can
> be started, moving it from installed to (eventually) unpacked, without
> causing monodoc-browser to be deconfigured, and this is nothing to do
> with triggers.
> 
> But as you point out there is an additional requirement (perhaps not
> specified in the docs) that all the dependencies should be satisfied
> when the postinst is run.
> 
> Would you like me to try to look into it and prepare a patch for dpkg ?
> (Do you need this to be fixed in squeeze or will wheezy/sid do?)

Thanks a lot for your analysis. So it seems like this is the assumption
that isn't being held here: that dependencies will be satisfied when
postinst is run.

It would be great if you could prepare a patch. This issue could come up
whenever libgtk2.0-cil and monodoc-browser are upgraded in the same run,
which certainly will happen with squeeze→wheezy upgrades. Since failing
upgrades is really unfriendly, a patch for squeeze's dpkg seems required
(or, if this proves to be too hard, we could work around it with my
mentioned hack of having monodoc-browser register gtk# into the GAC
itself, or || true the failing call since having outdated documentation
indices isn't the end of the world).
 
Cheers,

-- 
Iain Lane                                  [ iain@orangesquash.org.uk ]
Debian Developer                                   [ laney@debian.org ]
Ubuntu Developer                                   [ laney@ubuntu.com ]
PhD student                                       [ ial@cs.nott.ac.uk ]
[signature.asc (application/pgp-signature, inline)]

Bug reassigned from package 'monodoc-browser' to 'dpkg'. Request was from Iain Lane <laney@debian.org> to control@bugs.debian.org. (Fri, 25 May 2012 07:33:08 GMT) Full text and rfc822 format available.

Added indication that 671711 affects src:monodoc-browser Request was from Iain Lane <laney@debian.org> to control@bugs.debian.org. (Fri, 25 May 2012 07:33:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#671711; Package dpkg. (Sun, 27 May 2012 18:42:25 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 27 May 2012 18:42:25 GMT) Full text and rfc822 format available.

Message #28 received at 671711@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Iain Lane <laney@debian.org>, 671711@bugs.debian.org
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
Subject: Re: Bug#671711: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
Date: Sun, 27 May 2012 20:41:04 +0200
On Fri, 2012-05-25 at 08:30:28 +0100, Iain Lane wrote:
> Thanks a lot for your analysis. So it seems like this is the assumption
> that isn't being held here: that dependencies will be satisfied when
> postinst is run.

> It would be great if you could prepare a patch. This issue could come up
> whenever libgtk2.0-cil and monodoc-browser are upgraded in the same run,
> which certainly will happen with squeeze→wheezy upgrades. Since failing
> upgrades is really unfriendly, a patch for squeeze's dpkg seems required
> (or, if this proves to be too hard, we could work around it with my
> mentioned hack of having monodoc-browser register gtk# into the GAC
> itself, or || true the failing call since having outdated documentation
> indices isn't the end of the world).

I've prepared a minimal test case for the dpkg functional tests, and a
quick patch solving this, which checks that dependencies are satisfied
before processing the trigger, and otherwise deferring the package
to be trigproc()ed.

I'm running the entire pkg-tests now, and will be doing some cleanup
before pushing this, will also look into preparing a stable update
later on.

In any case I think you'll need to workaround this in your package
anway, as users are not usually required to have the latest stable
updates before dist-upgrading.

thanks,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#671711; Package dpkg. (Fri, 08 Jun 2012 05:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 08 Jun 2012 05:12:03 GMT) Full text and rfc822 format available.

Message #33 received at 671711@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Iain Lane <laney@debian.org>
Cc: Andreas Beckmann <debian@abeckmann.de>, 671711@bugs.debian.org, debian-dpkg@lists.debian.org, debian-devel@lists.debian.org
Subject: Re: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
Date: Fri, 8 Jun 2012 07:09:56 +0200
Hi!

On Wed, 2012-05-09 at 16:12:14 +0100, Iain Lane wrote:
> On Sun, May 06, 2012 at 10:37:53AM +0200, Andreas Beckmann wrote:
> > […]
> > 
> > during a test with piuparts I noticed your package fails to upgrade from
> > 'testing'.
> > It installed fine in 'testing', then the upgrade to 'sid' fails.
> > 
> > >From the attached log (scroll to the bottom...):
> > 
> >   Preparing to replace monodoc-clutter-manual 1.0.0~alpha3~git20090817.r1.349dba6-7 (using .../monodoc-clutter-manual_1.0.0~alpha3~git20090817.r1.349dba6-8_all.deb) ...
> >   Unpacking replacement monodoc-clutter-manual ...
> >   Processing triggers for monodoc-browser ...
> >   generating monodoc search index...
> >   grep: /etc/gre.d/*.conf: No such file or directory
> >   
> >   Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f' or one of its dependencies.
> >   File name: 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f'
> >   [ERROR] FATAL UNHANDLED EXCEPTION: System.IO.FileNotFoundException: Could not load file or assembly 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f' or one of its dependencies.
> >   File name: 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f'
> >   dpkg: error processing monodoc-browser (--unpack):
> >    subprocess installed post-installation script returned error exit status 1
> >   configured to not write apport reports
> >   Errors were encountered while processing:
> >    monodoc-browser
> 
> It's because libgtk2.0-cil (on which monodoc-browser depends) has been
> unpacked but not configured at this point. I thought (from reading
> /usr/share/doc/dpkg-dev/triggers.txt.gz):
> 
> ,----
> | Packages in t-awaited and t-pending demand satisfaction of their
> | dependencies just like packages in installed.
> `----
> 
> that I could assume this would be the case when running the trigger, but
> apparently not. What am I guaranteed here? I spoke to Colin Watson about
> this yesterday and he suggested that perhaps the postinst trigger could
> register gtk-sharp into the GAC itself, which would be somewhat
> unfortunate but would probably work if it is guaranteed that
> libgtk2.0-cil will be unpacked or better when the trigger is activated.

Hmmm, so I had prepared a patch which basically checks if the package
has its dependencies fulfilled before calling the postinst script with
"triggered", and otherwise defers the trigger processing for later (but
only as long as it is not running from inside the deferred trigproc run).

This fixes this specific case just fine (t-triggers-depends test
case in dpkg/pkg-tests.git), but this in turn creates problems with
packages with pending triggers depending on packages awaiting them,
as it forces breaking trigger cycles, which is not really a nice
upgrade path.

An immediate example of this is man-db and dpkg itself. While this
specific case could be fixed by removing the old versioned dpkg
dependency from man-db, I'm assuming other such cases might exist
on the archive, and I'm not prepared to add any such fix to dpkg
w/o further analysis.

In any case, this and most other similar cases would just disappear
by switching those triggers to the noawait variants, but that's not
supported by dpkg in stable so that would need to wait until after
wheezy.

OTOH I'm quite tired right now, and it's probable I'm missing
something obvious... but in view of the above possibly producing mass
breakage I've pulled out that patch from the dpkg 1.16.4 release which
I wanted to push yesterday already.

thanks,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#671711; Package dpkg. (Tue, 12 Jun 2012 08:21:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Iain Lane <laney@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 12 Jun 2012 08:21:10 GMT) Full text and rfc822 format available.

Message #38 received at 671711@bugs.debian.org (full text, mbox):

From: Iain Lane <laney@debian.org>
To: Andreas Beckmann <debian@abeckmann.de>, 671711@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
Date: Tue, 12 Jun 2012 09:20:17 +0100
[Message part 1 (text/plain, inline)]
Hi there,

[ dropping -devel ]

On Fri, Jun 08, 2012 at 07:09:56AM +0200, Guillem Jover wrote:
> Hi!
> […]
> Hmmm, so I had prepared a patch which basically checks if the package
> has its dependencies fulfilled before calling the postinst script with
> "triggered", and otherwise defers the trigger processing for later (but
> only as long as it is not running from inside the deferred trigproc run).
> 
> This fixes this specific case just fine (t-triggers-depends test
> case in dpkg/pkg-tests.git), but this in turn creates problems with
> packages with pending triggers depending on packages awaiting them,
> as it forces breaking trigger cycles, which is not really a nice
> upgrade path.
> 
> An immediate example of this is man-db and dpkg itself. While this
> specific case could be fixed by removing the old versioned dpkg
> dependency from man-db, I'm assuming other such cases might exist
> on the archive, and I'm not prepared to add any such fix to dpkg
> w/o further analysis.

Is it possible to detect that there is a cycle happening and revert to
the 'old' behaviour of just not considering satisfaction of depends?
 
> In any case, this and most other similar cases would just disappear
> by switching those triggers to the noawait variants, but that's not
> supported by dpkg in stable so that would need to wait until after
> wheezy.
> 
> OTOH I'm quite tired right now, and it's probable I'm missing
> something obvious... but in view of the above possibly producing mass
> breakage I've pulled out that patch from the dpkg 1.16.4 release which
> I wanted to push yesterday already.

OK. For mono-tools then, do we get that libgtk2.0-cil will be at least
unpacked when the trigger is processed? i.e. could we have the postinst
perform the GAC registration itself? Hmm, but that at least requires
mono-gac (on which libgtk2.0-cil transitively depends) to be unpacked
and for its postinst to be run too. Can we also assume that it will be
unpacked by dpkg's standard ordering?

Cheers,

-- 
Iain Lane                                  [ iain@orangesquash.org.uk ]
Debian Developer                                   [ laney@debian.org ]
Ubuntu Developer                                   [ laney@ubuntu.com ]
PhD student                                       [ ial@cs.nott.ac.uk ]
[signature.asc (application/pgp-signature, inline)]

Merged 671711 678848 Request was from Sébastien Villemot <sebastien.villemot@ens.fr> to control@bugs.debian.org. (Mon, 25 Jun 2012 09:39:29 GMT) Full text and rfc822 format available.

Added indication that 671711 affects liblapack3, libblas3, and octave Request was from Sébastien Villemot <sebastien.villemot@ens.fr> to control@bugs.debian.org. (Mon, 25 Jun 2012 09:39:31 GMT) Full text and rfc822 format available.

Added indication that 671711 affects octave-vrml Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Sat, 30 Jun 2012 21:36:17 GMT) Full text and rfc822 format available.

Marked as found in versions octave-vrml/1.0.13-1. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Sat, 30 Jun 2012 21:36:18 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#671711; Package dpkg. (Sun, 15 Jul 2012 16:51:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 15 Jul 2012 16:51:04 GMT) Full text and rfc822 format available.

Message #51 received at 671711@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: 671711@bugs.debian.org
Subject: Re: Bug#671711: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
Date: Sun, 15 Jul 2012 18:40:22 +0200
severity 671711 important
affects 671711 mono-tools
found 671711 dpkg/1.14.17
notfound 671711 monodoc-clutter-manual/1.0.0~alpha3~git20090817.r1.349dba6-8
notfound 671711 mono-tools/2.10-3
notfound 671711 octave-vrml/1.0.13-1
thanks

On Fri, 2012-06-08 at 07:09:56 +0200, Guillem Jover wrote:
> Hmmm, so I had prepared a patch which basically checks if the package
> has its dependencies fulfilled before calling the postinst script with
> "triggered", and otherwise defers the trigger processing for later (but
> only as long as it is not running from inside the deferred trigproc run).
> 
> This fixes this specific case just fine (t-triggers-depends test
> case in dpkg/pkg-tests.git), but this in turn creates problems with
> packages with pending triggers depending on packages awaiting them,
> as it forces breaking trigger cycles, which is not really a nice
> upgrade path.
> 
> An immediate example of this is man-db and dpkg itself. While this
> specific case could be fixed by removing the old versioned dpkg
> dependency from man-db, I'm assuming other such cases might exist
> on the archive, and I'm not prepared to add any such fix to dpkg
> w/o further analysis.
> 
> In any case, this and most other similar cases would just disappear
> by switching those triggers to the noawait variants, but that's not
> supported by dpkg in stable so that would need to wait until after
> wheezy.

Given the above, i.e. the fact that this behaviour, even if rather
unfortunate has been present since the introduction of triggers and
as such makes affected packages having to workaround the problems for
now, and that fixing it now would introduce regressions in other
situations I don't consider it RC, and I'm postponing the fix for
after wheezy, after the aforementioned regressions have been fixed
first.

thanks,
guillem



Severity set to 'important' from 'serious' Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Sun, 15 Jul 2012 16:51:07 GMT) Full text and rfc822 format available.

Added indication that 671711 affects mono-tools Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Sun, 15 Jul 2012 16:51:08 GMT) Full text and rfc822 format available.

Marked as found in versions dpkg/1.14.17. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Sun, 15 Jul 2012 16:51:09 GMT) Full text and rfc822 format available.

No longer marked as found in versions monodoc-clutter-manual/1.0.0~alpha3~git20090817.r1.349dba6-8. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Sun, 15 Jul 2012 16:51:10 GMT) Full text and rfc822 format available.

No longer marked as found in versions mono-tools/2.10-3. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Sun, 15 Jul 2012 16:51:11 GMT) Full text and rfc822 format available.

No longer marked as found in versions octave-vrml/1.0.13-1. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Sun, 15 Jul 2012 16:51:12 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#671711; Package dpkg. (Mon, 06 Aug 2012 08:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 06 Aug 2012 08:27:03 GMT) Full text and rfc822 format available.

Message #68 received at 671711@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Iain Lane <laney@debian.org>, Andreas Beckmann <debian@abeckmann.de>, 671711@bugs.debian.org, debian-dpkg@lists.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#671711: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
Date: Mon, 6 Aug 2012 10:22:11 +0200
Hi,

On Fri, 08 Jun 2012, Guillem Jover wrote:
> Hmmm, so I had prepared a patch which basically checks if the package
> has its dependencies fulfilled before calling the postinst script with
> "triggered", and otherwise defers the trigger processing for later (but
> only as long as it is not running from inside the deferred trigproc run).

Since #680626 showed that this is a recurring problem, it would be nice
if we could do supplementary tests with the fixed dpkg to get a better
idea of the amount of problems that it creates.

Can you push your fix somewhere so that we can make tests?

> This fixes this specific case just fine (t-triggers-depends test
> case in dpkg/pkg-tests.git), but this in turn creates problems with
> packages with pending triggers depending on packages awaiting them,
> as it forces breaking trigger cycles, which is not really a nice
> upgrade path.

Because of the trigger cycles, you opted to change nothing. What about
enforcing some requirements which are less strong that the one desired?
(Probably only as a temporary stop-gap measure until we're able to
switch back to the full requirement)

The problematic fix is to ensure the same requirements for "postinst
triggered" as for "postinst configure". But we could enforce some
requirements that would probably solve the issues we saw without
introducing cycles.

Indeed, I believe it's relatively safe to run "postinst triggered"
when:
- the dependencies are at least in status triggers-awaited
  (this would go counter the logic that triggers-awaited package
  are not really configured, but it would acknowledge the fact
  that most packages should use "interest-noawait" instead)
- the dependency was already configured in a version (Config-Version
  field) which satisfies the dependency

What do you think?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



Added indication that 671711 affects src:octave Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Mon, 13 Aug 2012 15:51:07 GMT) Full text and rfc822 format available.

Disconnected #678848 from all other report(s). Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Mon, 13 Aug 2012 18:18:05 GMT) Full text and rfc822 format available.

Changed Bug title to 'dpkg: runs trigger processing even if depedencies are not satisfied' from 'monodoc-browser: fails to upgrade from 'testing'' Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Mon, 13 Aug 2012 18:18:06 GMT) Full text and rfc822 format available.

Merged 671711 678848 Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Mon, 13 Aug 2012 18:33:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#671711; Package dpkg. (Tue, 01 Jan 2013 14:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 01 Jan 2013 14:21:03 GMT) Full text and rfc822 format available.

Message #81 received at 671711@bugs.debian.org (full text, mbox):

From: Julien Cristau <jcristau@debian.org>
To: Daniel Pocock <daniel@pocock.com.au>, 685243@bugs.debian.org
Cc: 671711@bugs.debian.org
Subject: Re: Bug#685243: vlc: breaks squeeze-wheezy upgrade into very bad state
Date: Tue, 1 Jan 2013 15:19:24 +0100
[Message part 1 (text/plain, inline)]
On Sat, Aug 18, 2012 at 18:20:48 +0000, Daniel Pocock wrote:

> Package: vlc-nox
> Version: 1.1.3-1squeeze6
> Severity: important
> 
> 
> My box is amd64, running squeeze
> 
> I started an upgrade to wheezy,
> 
> apt-get upgrade
> 
> was successful.  Then I ran
> 
> apt-get dist-upgrade
> 
> and it failed here:
> 
> Processing triggers for vlc-nox ...
> /usr/lib/vlc/vlc-cache-gen: error while loading shared libraries:
> libvlccore.so.5: cannot open shared object file: No such file or directory
> dpkg: error processing vlc-nox (--unpack):
>  subprocess installed post-installation script returned error exit
> status 127
> configured to not write apport reports
>                                       Errors were encountered while
> processing:
>  vlc-nox
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
Please provide the full upgrade log and contents of /var/lib/dpkg/status
before and after the upgrade.

I suspect this is yet another case of dpkg triggering unconfigured
packages (#671711).  Which dpkg maintainers don't plan on fixing, and
recommend working around in other packages.  Except I'm not aware of any
work-around having been suggested.

Cheers,
Julien
[signature.asc (application/pgp-signature, inline)]

Changed Bug submitter to 'Andreas Beckmann <anbe@debian.org>' from 'Andreas Beckmann <debian@abeckmann.de>' Request was from Andreas Beckmann <anbe@debian.org> to control@bugs.debian.org. (Sat, 26 Jan 2013 06:28:53 GMT) Full text and rfc822 format available.

Merged 671711 678848 701047 Request was from Sébastien Villemot <sebastien@debian.org> to 701047-submit@bugs.debian.org. (Wed, 20 Feb 2013 21:57:09 GMT) Full text and rfc822 format available.

Added indication that bug 671711 blocks 680626 Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Sun, 28 Apr 2013 12:15:10 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 671711: 707129 Request was from Guillem Jover <guillem@debian.org> to submit@bugs.debian.org. (Tue, 07 May 2013 17:45:07 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 671711: 707133 Request was from Guillem Jover <guillem@debian.org> to submit@bugs.debian.org. (Tue, 07 May 2013 17:51:19 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#671711; Package dpkg. (Sun, 04 Aug 2013 01:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 04 Aug 2013 01:09:04 GMT) Full text and rfc822 format available.

Message #96 received at 671711@bugs.debian.org (full text, mbox):

From: Charles Plessy <plessy@debian.org>
To: 671711@bugs.debian.org
Subject: Re: Bug#671711: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
Date: Sun, 4 Aug 2013 10:08:16 +0900
Le Sun, Jul 15, 2012 at 06:40:22PM +0200, Guillem Jover a écrit :
> 
> Given the above, i.e. the fact that this behaviour, even if rather
> unfortunate has been present since the introduction of triggers and
> as such makes affected packages having to workaround the problems for
> now, and that fixing it now would introduce regressions in other
> situations I don't consider it RC, and I'm postponing the fix for
> after wheezy, after the aforementioned regressions have been fixed
> first.

Hi Guillem,

what is the state of this bug now that Wheezy has been released ?  Do you think
that you will have soon opportunities to resume the work ?  Or would it make
sense to call for contributions on debian-dpkg or debian-devel, for instance ?

The reason I ask is that this bug seems to have chilling effects regarding
documenting triggers in the Policy, which I think is unfortunate since the
proposed addition to the Policy will, in my opinion, make it easier for our
developers to use and understand triggers.

Have a nice Sunday,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 16 04:13:40 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.