On Tue, 8 Jun 2004, Matthew Palmer wrote:

> Whoops, sorry about that.  I thought it did.

no problem. i wasn't upset.. just a note ;)

>
> > 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.

libapache2-mod-php4 does too and it pulls in apache2-mpm-prefork.

> 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.

Basically in this setup apache2 and apache-common are pulled in. Nothing
bad until now, but if a user wants only apache1.3, he or she will endup
with both a1.3 and a2 installed.

> > 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?

That is my point. I have no idea. I have been rechecking all the cvs
history to be sure that was not introduced and removed for a mistake.

> > 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.

Ok this has been discussed already with Joey H. as part of dh_installinit.
force-reload is an alias to reload atm and this can be fixed.

> > 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.

I agree. I can't see any other way around it.

Fabio

-- 
<user> fajita: step one
<fajita> Whatever the problem, step one is always to look in the error log.
<user> fajita: step two
<fajita> When in danger or in doubt, step two is to scream and shout.


Reply via email to