[Pkg-haskell-maintainers] Bug#772867: Bug#772867: hoogle: Trigger cycle causes dpkg to fail processing

[Guillem Jover]

Hi!

On Fri, 2014-12-12 at 09:34:58 +0100, Joachim Breitner wrote:
> Am Donnerstag, den 11.12.2014, 21:30 +0100 schrieb Guillem Jover:
> > This package can get involved in a trigger cycle. The problem is that
> > it installs interests on /usr/lib/ghc-doc/hoogle with files there
> > provided by ghc-doc, which is directly or transitively depended on
> > by hoogle itself.
> > 
> > 
> > A solution to the above is to simply switch the triggers to their
> > noawait variants, in this case from «interest» to «interest-noawait»,
> > as long as they are not critical for the activating packages, which I
> > think is the case here (?). Otherwise a fix might unfortunatly be more
> > involved.
> 
> in ghc-7.6.3-20, all triggers are now noawait triggers. Did you check it
> against that version?

Any trigger that is noawait cannot get into a cycle. Those where
thus excluded from the analysis (see the thread starting at
<https://lists.debian.org/debian-dpkg/2014/12/msg00015.html> if you
are interested on its details).

And, sorry I see you asked debian-dpkg about that issue, but no one
replied, I'll try to get a look to check if that fix was correct.

> Is it sufficient that one trigger in the cycle is no-await, or should I
> change hoogle’s triggers as well?

It is sufficient for just one trigger to be _await_ for a cycle to
form, in this case the cycle is created due to hoogle alone. The
problem is that hoogle is interested in a path, that path is provided
by another package which will be placed in status triggers-awaited
(which do not satisfy dependencies), and at the same time the
interested package depends directly or indirectly on the package
activating the trigger, so the dependencies cannot be resolved because
to process the trigger the dependencies need to be satisfied. Hope this
clarifies.

> (I’ll do it, but the question is whether this needs to enter testing.)

Yes, this would need to enter testing, this is particularly relevant on
upgrade scenarios.

Thanks,
Guillem