Re: Bug#786763: redmine: error messages during update of ruby-rails packages
On 2015-06-12 15:36, Antonio Terceiro wrote:
> Hello Niels,
>
> Thanks for your insight. Maybe you can help me a little further?
>
> On Sat, May 30, 2015 at 07:46:02AM +0200, Niels Thykier wrote:
>> The output from dpkg suggests redmine has an /awaiting/ trigger cycle.
>> In particular, on itself? Indeed, redmine has the following triggers:
>>
>> """
>> interest /usr/share/redmine/plugins
>> interest /usr/lib/ruby/vendor_ruby
>> """
>> (From
>> http://anonscm.debian.org/cgit/pkg-ruby-extras/redmine.git/tree/debian/redmine.triggers)
>
> redmine does not install files on either of those locations, so how
> could it be triggering itself?
>
Ok, admittedly look a bit weird. I am not sure what happened here and
leave it to the dpkg maintainers.
>> If possible, please consider switching these to noawait variants (though
>> note that noawait may defer the trigger a bit longer). Alternatively,
>> if noawait triggers do not provide enough guarantees, you may have to
>> replace the interest triggers all together. Please note that:
>>
>> * No package /depending/ on redmine can use an "await" trigger.
>> If they do, it will lead to a trigger cycle.
>>
>> Please see man 5 deb-triggers for more information.
>
> For both triggers, redmine could be acvitated at the very end of the
> upgrade without problem. So IIUC just switching to interest-noawait
> would fix this?
>
Indeed, I would expect it to do so unless you have found a bug in dpkg.
However, /even if/ you found a bug in dpkg, I would /still/ recommend
using interest-noawait as interest(-await) will break redmine when there
are reverse dependencies that /do/ ship files in those directories.
E.g. redmine + redmine-plugin-recaptcha should be sufficient to
trigger this issue. I cannot remember offhand the necessary dpkg
invocations to trigger the issue (emulating an possible upgrade
situation), but if necessary I can look it up.
Thanks,
~Niels
Reply to: