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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org