« Return to Thread: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
Re: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
by Iain Lane-8
::
Rate this Message:
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@... ]
Debian Developer [ laney@... ]
Ubuntu Developer [ laney@... ]
PhD student [ ial@... ]
[ 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.
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@... ]
Debian Developer [ laney@... ]
Ubuntu Developer [ laney@... ]
PhD student [ ial@... ]
signature.asc (853 bytes) « Return to Thread: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
| Free embeddable forum powered by Nabble | Forum Help |
