Re: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
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
Reply to: