[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'



Hi there,

[ dropping -devel ]

On Fri, Jun 08, 2012 at 07:09:56AM +0200, Guillem Jover wrote:
> Hi!
> […]
> 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
> 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.

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?

Cheers,

-- 
Iain Lane                                  [ iain@orangesquash.org.uk ]
Debian Developer                                   [ laney@debian.org ]
Ubuntu Developer                                   [ laney@ubuntu.com ]
PhD student                                       [ ial@cs.nott.ac.uk ]

Attachment: signature.asc
Description: Digital signature


Reply to: