Hi,
This kind of bug is infuriating me these days and I don't feel I'm in a
good state of mind to deal with them.
In this case, due to not using a Debian-specific way to start/stop
services, we face a full removal from Debian.... again.
This happens on a regular basis since the beginning of the year, and now
it's even more difficult to deal with since Debian is frozen and this
requires maintaining a new Debian-Jessie-specific branch with only
"release-critical" bugs fixed.
I now understand why FusionForge didn't make it in the last Debian
release: I thought it was a slip-up, but I now see it requires time and
emotional energy.
I can see a few choices to cope with this:
- drop fusionforge from Debian, maintain our own repository, stop caring
and waste no more time
- attempt to negociate the severity of such bugs (possibly explaining
that receiving a RC with copy/paste first thing in the morning is, well,
improvable)
- fix the bug, and complexify the GUM to deal with this too (because I
deliberately used "service" everywhere, as that command is the most
portable and available one).
What do you think?
- Sylvain
-------- Message transféré --------
Sujet : Bug#771619: fusionforge: plugin postinst script uses 'service'
instead of invoke-rc.d
Date de renvoi : Mon, 01 Dec 2014 02:33:02 +0000
De (renvoi) : Andreas Beckmann <a...@debian.org>
Pour (renvoi) : debian-bugs-d...@lists.debian.org
Copie (renvoi) : Roland Mas <lola...@debian.org>
Date : Mon, 01 Dec 2014 03:28:56 +0100
De : Andreas Beckmann <a...@debian.org>
Répondre à : Andreas Beckmann <a...@debian.org>, 771...@bugs.debian.org
Pour : Debian Bug Tracking System <sub...@bugs.debian.org>
Source: fusionforge
Version: 5.3.2+20141104-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + fusionforge-plugin-mediawiki fusionforge-plugin-moinmoin
fusionforge-plugin-scmgit fusionforge-plugin-scmbzr fusionforge-plugin-scmdarcs
fusionforge-plugin-authhttpd
Hi,
during a test with piuparts I noticed your package fails to install.
digging further into it lead me to a 'service apache2 reload' call in
the postinst. Not using invoke-rc.d to manipulate services violates
policy 9.3.3.2 and ignores policy-rc.d.
See https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
and /usr/share/doc/sysv-rc/README.invoke-rc.d.gz as well
as /usr/share/doc/sysv-rc/README.policy-rc.d.gz
(the 'service apache2 reload' failed since apache ws not running - not
permitted by policy-rc.d. while you may get a running database server
from piuparts for your package being tested, there is (currently)
no runnning apache instance available)
Selecting previously unselected package fusionforge-plugin-authhttpd.
(Reading database ... 15746 files and directories currently installed.)
Preparing to unpack .../fusionforge-plugin-authhttpd_5.3.2+20141104-1_all.deb
...
Unpacking fusionforge-plugin-authhttpd (5.3.2+20141104-1) ...
Setting up fusionforge-plugin-authhttpd (5.3.2+20141104-1) ...
Entering upgrade-db.php
Reloading web server: apache2 failed!
Apache2 is not running ... (warning).
dpkg: error processing package fusionforge-plugin-authhttpd (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
fusionforge-plugin-authhttpd
E: Sub-process /usr/bin/dpkg returned an error code (1)
cheers,
Andreas
_______________________________________________
Fusionforge-general mailing list
Fusionforge-general@lists.fusionforge.org
http://lists.fusionforge.org/cgi-bin/mailman/listinfo/fusionforge-general