On Fri, Jun 08, 2012 at 07:09:56AM +0200, Guillem Jover wrote:
> 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.
Is it possible to detect that there is a cycle happening and revert to
the 'old' behaviour of just not considering satisfaction of depends?
> 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
> 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.
OK. For mono-tools then, do we get that libgtk2.0-cil will be at least
unpacked when the trigger is processed? i.e. could we have the postinst
perform the GAC registration itself? Hmm, but that at least requires
mono-gac (on which libgtk2.0-cil transitively depends) to be unpacked
and for its postinst to be run too. Can we also assume that it will be
unpacked by dpkg's standard ordering?