Bug 2900

Summary:	apache is not started automatically after install
Product:	Mageia	Reporter:	AL13N <alien>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	Normal	CC:	alien, dmorganec, guillomovitch, marja11
Version:	1
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:	apache2	CVE:
Status comment:

Description AL13N 2011-10-02 11:23:16 CEST

1. install a mga1
2. install something that requires apache (like urpmi-proxy) (or apache itself)
3. service httpd is not started.

afaik apache has no maintainer, so if everyone agrees i'd do an update for mga1 that starts httpd after installing...

AL13N 2011-10-02 11:24:52 CEST

CC: (none) => alien, guillomovitch

Comment 1 Manuel Hiebel 2011-10-02 12:33:26 CEST

apache dmorgan
but dmorgan is maybe very busy :)

CC: (none) => dmorganec

Comment 2 AL13N 2011-10-02 13:38:28 CEST

well, he may be :-) ; but if he agrees with me, i can try to fix this myself

Comment 3 Guillaume Rousse 2011-10-04 11:28:08 CEST

That's expected behaviour: no automatic start of any service after package automatically, you're supposed to configure it first.

What is expected, tough, is automatic activation of the service after installation, to ensure starting at boot time. This behaviour may be broken since switch to native systemd control, but that's not apache-specific.

Comment 4 AL13N 2011-10-04 20:06:15 CEST

(In reply to comment #3)
> That's expected behaviour: no automatic start of any service after package
> automatically, you're supposed to configure it first.
> 
> What is expected, tough, is automatic activation of the service after
> installation, to ensure starting at boot time. This behaviour may be broken
> since switch to native systemd control, but that's not apache-specific.

this is for mageia1, so systemd is not an issue here.

Is this a policy we want to continue? no service at all is started after installation? or only the services that are remotely accessible by default?

so in this case, only adding a README.urpmi will "solve" this issue?

Comment 5 Marja Van Waes 2011-12-05 17:09:33 CET

@ AL13N

No one replied to your question.

Do you want to discuss this on the dev ml or are you willing to add that README.urpmi?

CC: (none) => marja11

Comment 6 AL13N 2011-12-05 17:29:45 CET

(In reply to comment #5)
> @ AL13N
> 
> No one replied to your question.

;_; story of my life :-)

> Do you want to discuss this on the dev ml or are you willing to add that
> README.urpmi?

if that's the policy, then that's the policy, i think it's been discussed.

the README.urpmi is meant for urpmi-proxy (ie: that it's dependant on apache and that you should make sure it's started or urpmi-proxy will not work...), i'll have to remember and add that...

Comment 7 Marja Van Waes 2011-12-05 21:23:18 CET

(In reply to comment #6)

> 
> if that's the policy, then that's the policy, i think it's been discussed.
> 
> the README.urpmi is meant for urpmi-proxy (ie: that it's dependant on apache
> and that you should make sure it's started or urpmi-proxy will not work...),
> i'll have to remember and add that...

Is it OK then, to put urpmi-proxy in the RPM Package: field, and to assign this bug to you?

Comment 8 AL13N 2011-12-05 21:58:22 CET

nah, just close it, i've added README.urpmi to urpmi-proxy just now :-)

Comment 9 Marja Van Waes 2011-12-05 22:09:33 CET

(In reply to comment #8)
> nah, just close it, i've added README.urpmi to urpmi-proxy just now :-)

Wow, you're fast! :D

Closing

Status: NEW => RESOLVED
Resolution: (none) => INVALID