Greetings, [ I already asked this on d-dpkg, but go no response, so am "re-posting" this question to -devel. The original report along with full log is in #671711 ] 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 at UDS 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? Or, can anyone suggest a nice solution to this bug? :-) Cheers, -- Iain Lane [ iain@orangesquash.org.uk ] Debian Developer [ laney@debian.org ] Ubuntu Developer [ laney@ubuntu.com ] PhD student [ ial@cs.nott.ac.uk ]
Attachment:
signature.asc
Description: Digital signature