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@... ]
Debian Developer [
laney@... ]
Ubuntu Developer [
laney@... ]
PhD student [
ial@... ]