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 [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] PhD student [ i...@cs.nott.ac.uk ]
signature.asc
Description: Digital signature
