Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[Thorsten Glaser]

On Mon, 15 Dec 2014, b...@debian.org wrote:

>   "Also I suppose using 'interest-nowait' will also not be triggered
>on 'apt-get upgrade' in Debian 7?",

It is triggered on upgrade of the packages writing to the interested
directories (mediawiki, mediawiki-extension-*).

Upgrades of the package _with_ the trigger usually only run the
postinst configure instead, as usual.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[beuc]

On Mon, Dec 15, 2014 at 05:40:35PM +0100, Thorsten Glaser wrote:
> On Mon, 15 Dec 2014, b...@debian.org wrote:
> 
> > Also I suppose using 'triggers-pending' won't work correctly in Debian 7?
> 
> What is “triggers-pending”?

I meant:
  "Also I suppose using 'interest-nowait' will also not be triggered
   on 'apt-get upgrade' in Debian 7?",
sorry.

-- 
Sylvain


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[Thorsten Glaser]

On Mon, 15 Dec 2014, b...@debian.org wrote:

> Also I suppose using 'triggers-pending' won't work correctly in Debian 7?

What is “triggers-pending”?


I just did one change, in tarent’s FusionForge variant,
and this works for me on wheezy and sid:

On Fri, 12 Dec 2014, Guillem Jover wrote:

> > command group. So, a simple s/^interest/&-noawait/ on the triggers file
> > would be all that’s needed for that?
>
> Yes.

This one. No touching postinst.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[beuc]

On Mon, Dec 15, 2014 at 05:12:08PM +0100, Guillem Jover wrote:
> On Mon, 2014-12-15 at 14:00:36 +0100, b...@debian.org wrote:
> > So far my tests show that 'apt-get upgrade' doesn't start the noawait
> > triggers.  The fusionforge-plugin-mediawiki is marked
> > 'triggers-pending' but apparently the user has to do something more
> > manually, which is not satisfying.
> > Any suggestion?
> 
> I don't understand the problem, can you expand? Or is this simply a
> problem of using dpkg from testing, if so, please just test with sid.

Well when a dpkg fix is on the way, make sure to mention it clearly :)
> > > dpkg was buggy and never performed dependency satisfiability checks
> > > when trying to process triggers. This was fixed in dpkg 1.17.17.

Also I suppose using 'triggers-pending' won't work correctly in Debian 7?

-- 
Sylvain


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[Guillem Jover]

On Mon, 2014-12-15 at 14:00:36 +0100, b...@debian.org wrote:
> On Sun, Dec 14, 2014 at 02:28:26PM +0100, Guillem Jover wrote:
> > On Fri, 2014-12-12 at 17:35:36 +0100, Thorsten Glaser wrote:
> > > So, with -noawait, the triggers just run later, but the dependency
> > > is satisfied early, right?
> > 
> > Think of it as an asynchronouse notification that something changed in
> > another package vs a notification that the triggering package needs
> > something to be processed to be able to declare itself as configured.
> > 
> > In case of -noawait, the triggering package never gets placed in a
> > triggers-awaited state, so it can always satisfy dependencies when it
> > has been configured.

> So far my tests show that 'apt-get upgrade' doesn't start the noawait
> triggers.  The fusionforge-plugin-mediawiki is marked
> 'triggers-pending' but apparently the user has to do something more
> manually, which is not satisfying.
> Any suggestion?

I don't understand the problem, can you expand? Or is this simply a
problem of using dpkg from testing, if so, please just test with sid.

> > On Fri, 2014-12-12 at 17:40:43 +0100, b...@debian.org wrote:
> > > There's one point I'd like to clarify: how comes we never had any
> > > issues with this?
> > > 
> > > E.g. I don't see any warning here:
> > > http://buildbot.fusionforge.org/job/fusionforge-53-functests-deb/os=debian7/33/consoleFull
> > 
> > dpkg was buggy and never performed dependency satisfiability checks
> > when trying to process triggers. This was fixed in dpkg 1.17.17.
> 
> Well we didn't have any issue here either :/
> http://buildbot.fusionforge.org/job/fusionforge-53-functests-deb/os=debian8/33/consoleFull
> 
> However I can reproduce the problem by upgrading/downgrading mediawiki.

That should be enough to demonstrate the problem, yes.

> How exactly did you "trigger" this bug? ;)

I didn't, we just found it by analysing [0] the archive for such issues.
That does not mean this cannot happen, it might mean not enough people
have been using a recent dpkg, or upgraded those packages, etc, the
problem is that it might happen depending on the upgrade solution
chosen by the frontend, or on what the user has installed and to what
is being tried to upgrade to.

[0] ,
thread strting there.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[beuc]

Hi,

On Sun, Dec 14, 2014 at 02:28:26PM +0100, Guillem Jover wrote:
> On Fri, 2014-12-12 at 17:35:36 +0100, Thorsten Glaser wrote:
> > So, with -noawait, the triggers just run later, but the dependency
> > is satisfied early, right?
> 
> Think of it as an asynchronouse notification that something changed in
> another package vs a notification that the triggering package needs
> something to be processed to be able to declare itself as configured.
> 
> In case of -noawait, the triggering package never gets placed in a
> triggers-awaited state, so it can always satisfy dependencies when it
> has been configured.

So far my tests show that 'apt-get upgrade' doesn't start the noawait
triggers.  The fusionforge-plugin-mediawiki is marked
'triggers-pending' but apparently the user has to do something more
manually, which is not satisfying.
Any suggestion?


> On Fri, 2014-12-12 at 17:40:43 +0100, b...@debian.org wrote:
> > There's one point I'd like to clarify: how comes we never had any
> > issues with this?
> > 
> > E.g. I don't see any warning here:
> > http://buildbot.fusionforge.org/job/fusionforge-53-functests-deb/os=debian7/33/consoleFull
> 
> dpkg was buggy and never performed dependency satisfiability checks
> when trying to process triggers. This was fixed in dpkg 1.17.17.

Well we didn't have any issue here either :/
http://buildbot.fusionforge.org/job/fusionforge-53-functests-deb/os=debian8/33/consoleFull

However I can reproduce the problem by upgrading/downgrading mediawiki.
How exactly did you "trigger" this bug? ;)

-- 
Sylvain


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[Guillem Jover]

Hi!

On Fri, 2014-12-12 at 17:35:36 +0100, Thorsten Glaser wrote:
> So, with -noawait, the triggers just run later, but the dependency
> is satisfied early, right?

Think of it as an asynchronouse notification that something changed in
another package vs a notification that the triggering package needs
something to be processed to be able to declare itself as configured.

In case of -noawait, the triggering package never gets placed in a
triggers-awaited state, so it can always satisfy dependencies when it
has been configured.

On Fri, 2014-12-12 at 17:40:43 +0100, b...@debian.org wrote:
> There's one point I'd like to clarify: how comes we never had any
> issues with this?
> 
> E.g. I don't see any warning here:
> http://buildbot.fusionforge.org/job/fusionforge-53-functests-deb/os=debian7/33/consoleFull

dpkg was buggy and never performed dependency satisfiability checks
when trying to process triggers. This was fixed in dpkg 1.17.17.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[beuc]

On Fri, Dec 12, 2014 at 05:29:17PM +0100, Guillem Jover wrote:
> On Fri, 2014-12-12 at 11:30:59 +0100, Thorsten Glaser wrote:
> > On Thu, 11 Dec 2014, Guillem Jover wrote:
> > > This package can get involved in a trigger cycle. The problem is that
> > > it installs interests on /usr/share/mediawiki with files there
> > > provided by mediawiki and mediawiki-classes, which are directly or
> > > transitively depended on byfusionforge-plugin-mediawiki itself.
> > 
> > Can you please explain how/why this can make trigger cycles?
> 
> Sure. The fusionforge-plugin-mediawiki package is interested in a path,
> that path is provided by say mediawiki, when installing mediawiki,
> that package gets placed in triggers-awaited state (which does not
> satisfy dependencies), and because to process the pending triggers in
> fusionforge-plugin-mediawiki all dependencies need to be satisfied
> dpkg cannot progress, and thus the trigger cycle. Hope that clarifies.

There's one point I'd like to clarify: how comes we never had any
issues with this?

E.g. I don't see any warning here:
http://buildbot.fusionforge.org/job/fusionforge-53-functests-deb/os=debian7/33/consoleFull

-- 
Sylvain


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[Thorsten Glaser]

On Fri, 12 Dec 2014, Guillem Jover wrote:

> > Can you please explain how/why this can make trigger cycles?
> 
> Sure. The fusionforge-plugin-mediawiki package is interested in a path,
> that path is provided by say mediawiki, when installing mediawiki,
> that package gets placed in triggers-awaited state (which does not
> satisfy dependencies), and because to process the pending triggers in
> fusionforge-plugin-mediawiki all dependencies need to be satisfied
> dpkg cannot progress, and thus the trigger cycle. Hope that clarifies.

Ah, thanks! That indeed clarifies.

So, with -noawait, the triggers just run later, but the dependency
is satisfied early, right?

> > command group. So, a simple s/^interest/&-noawait/ on the triggers file
> > would be all that’s needed for that?
> 
> Yes. It seems approrpiate, because here it's just enabling additional
> stuff from fusionforge-plugin-mediawiki side, and not something that
> the triggering packages are really concerned about.

OK, thanks.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[Guillem Jover]

Hi!

On Fri, 2014-12-12 at 11:30:59 +0100, Thorsten Glaser wrote:
> On Thu, 11 Dec 2014, Guillem Jover wrote:
> > This package can get involved in a trigger cycle. The problem is that
> > it installs interests on /usr/share/mediawiki with files there
> > provided by mediawiki and mediawiki-classes, which are directly or
> > transitively depended on byfusionforge-plugin-mediawiki itself.
> 
> Can you please explain how/why this can make trigger cycles?

Sure. The fusionforge-plugin-mediawiki package is interested in a path,
that path is provided by say mediawiki, when installing mediawiki,
that package gets placed in triggers-awaited state (which does not
satisfy dependencies), and because to process the pending triggers in
fusionforge-plugin-mediawiki all dependencies need to be satisfied
dpkg cannot progress, and thus the trigger cycle. Hope that clarifies.

> > A solution to the above is to simply switch the triggers to their
> > noawait variants, in this case from «interest» to «interest-noawait»,
> 
> That’s probably sensible anyway…
> 
> > as long as they are not critical for the activating packages, which I
> > cannot tell here. Otherwise a fix might unfortunatly be more involved.
> 
> The idea is that, if a new version of mediawiki, or a new extension,
> or a new version of an extension, is installed, that mediawiki’s
> upgrade.php script is run on all wikis of the fusionforge wiki farm.
> This need not be “right now”, but should be done in the same apt/dpkg
> command group. So, a simple s/^interest/&-noawait/ on the triggers file
> would be all that’s needed for that?

Yes. It seems approrpiate, because here it's just enabling additional
stuff from fusionforge-plugin-mediawiki side, and not something that
the triggering packages are really concerned about.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[Thorsten Glaser]

Hi Guillem!

On Thu, 11 Dec 2014, Guillem Jover wrote:

> This package can get involved in a trigger cycle. The problem is that
> it installs interests on /usr/share/mediawiki with files there
> provided by mediawiki and mediawiki-classes, which are directly or
> transitively depended on byfusionforge-plugin-mediawiki itself.

Can you please explain how/why this can make trigger cycles?

> A solution to the above is to simply switch the triggers to their
> noawait variants, in this case from «interest» to «interest-noawait»,

That’s probably sensible anyway…

> as long as they are not critical for the activating packages, which I
> cannot tell here. Otherwise a fix might unfortunatly be more involved.

The idea is that, if a new version of mediawiki, or a new extension,
or a new version of an extension, is installed, that mediawiki’s
upgrade.php script is run on all wikis of the fusionforge wiki farm.
This need not be “right now”, but should be done in the same apt/dpkg
command group. So, a simple s/^interest/&-noawait/ on the triggers file
would be all that’s needed for that?

Thanks,
//mirabilos (hat: FusionForge contributor)
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[Guillem Jover]

Package: fusionforge-plugin-mediawiki
Version: 5.3.2+20141104-2
Severity: serious

Hi!

This package can get involved in a trigger cycle. The problem is that
it installs interests on /usr/share/mediawiki with files there
provided by mediawiki and mediawiki-classes, which are directly or
transitively depended on byfusionforge-plugin-mediawiki 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
cannot tell here. Otherwise a fix might unfortunatly be more involved.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org