Re: Bug#330727: libapache-mod-auth-mysql: postrm script fails

2005-10-03 Thread Matthew Palmer
reassign 330727 apache-common
thanks

On Thu, Sep 29, 2005 at 04:11:22PM +0100, Edward Allcutt wrote:
 The postrm runs /usr/sbin/modules-config. since libapache-mod-auth-mysql
 depends on apache-common which owns this, this is probably fine. However
 /usr/sbin/modules-config fails if apache is not installed which results
 in the postrm failing and hence the package is uninstallable.
 This may of course be a bug with apache-common, but I think the postrm
 should allow for this possible failure.

Apart from tacking an || true onto the modules-config invocation (which
can hide a multitude of sins) I'm not sure how the libapache-mod-auth-mysql
postrm *could* allow for the possible failure of an external program,
especially when a failure of that program should be something that
libapache-mod-auth-mysql should know about and pitch a small fit.

I really think that modules-config failing when the apache package itself
isn't installed is an apache-common problem, so I'm reassigning it there.

- Matt


signature.asc
Description: Digital signature


Bug#252067: more info?

2004-06-08 Thread Matthew Palmer
On Tue, Jun 08, 2004 at 09:45:37AM +0200, Fabio Massimo Di Nitto wrote:
 On Tue, 8 Jun 2004, Christopher Mann wrote:
 
  Fabio Massimo Di Nitto wrote:
 
  Hi guys,
 please CC the maintainer when reassigning bugs since the BTS
  doesn't do that automatically.

Whoops, sorry about that.  I thought it did.

 My best guess is that, since installing php4-sqlite that depends on
 php4api that is provided by 2 packages that pulls in apache and apache2,

There are only two packages that I can find in unstable that provide
phpapi-20040918: php4 and php4-cgi.  Nothing is providing zendapi-20020429. 
php4 depends on apache-common.  I'm not quite sure how that qualifies as a
dependency nightmare, nor am I sure how php4-sqlite would manage to pull in
apache2.  I can't find a dependency link on it.

 apache2 was running before apache. Both of them listening on port 80. As a
 result apache failed to start.

But if /etc/init.d/apache{,-ssl} doesn't call apachectl, how did we manage
to end up with the apachectl help message, no matter what might have already
been running?

 Matthew btw php4-sqlite call to apache restart seems ok even if
 force-reload is not required (and your prerm script is broken ;)).

reload fails if apache isn't already running.  I feel that's probably a bug
in apache, even though Policy doesn't forbid it (we really need an
initscript argument that says restart if already running, or succeed with
no action if not already running).  The only way to reload without a
possible failure is force-reload.

 In anycase i can't reproduce the problem here. Can anybody provide me with
 more info?

I can't reproduce it either.  Personally, the only way I can manage to
rationalise it is that someone has done an ln -sf /usr/sbin/apachectl
/etc/init.d/apache.  Nothing else makes the slightest sense.

- Matt