Discussion:
How to use /etc/php5/conf.d ?
Olly Betts
2007-06-06 18:40:21 UTC
Permalink
I maintain the php5-xapian package. Currently it modifies php.ini upon
installation to append "extension=xapian.so" (after checking with the
user using debconf), but I notice that /etc/php5/conf.d now exists which
offers a much cleaner solution.

Looking at the PHP policy draft it appears that this hasn't yet been
updated for that change, as it says:

http://webapps-common.alioth.debian.org/draft-php/html/ch-php-int.html

2.2.3 Configuration files

Each PHP engine has a seperate configuration file located at
/etc/phpPHPVERSION/PHPSAPI/php.ini

Additionally, each engine provides a directory at
/etc/phpPHPVERSION/PHPSAPI/conf.d where 3rd party PHP libraries and
modules can provide additional configuration information.

XXX this second part is not yet true.

It looks like the second part is now mostly true. README.Debian in the
PHP packages gives some information - it says:

Additionally, each SAPI is configured with the compile-time option

--with-config-file-scan-dir=/etc/php5/$SAPI/conf.d

which for all SAPI's is actually a symlink pointing to a central
directory /etc/php5/conf.d. Any file found in this directory ending
in .ini will be treated as a configuration file by the php SAPI.

Which seems to describe the situation correctly, so I can just package
"/etc/php5/conf.d/xapian.ini" containing "extension=xapian.so", and
I think I don't need to mark it as a conffile.

README.Debian continues:

The rationale with this method is that each SAPI can thus be
identically configured with a minimal amount of conffile handling,
but at the same time if you want to have SAPI-specific configuration,
you can just remove the symlink.

Should a package attempt to do anything special in the situation?
Should I be trying to copy xapian.ini into the conf.d for every SAPI
or is it assumed that this is up to the sysadmin if he or she removes
the symlinks?

And is there a recommended way to handle edits made to php.ini by the
currently install version of a package when moving to using conf.d?
I can easily check for the appropriate line and remove it if present,
though I can't tell if it was added by my postinst or the sysadmin.

Cheers,
Olly
--
To UNSUBSCRIBE, email to debian-webapps-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
sean finney
2007-06-06 20:45:25 UTC
Permalink
hey olly,

On Wednesday 06 June 2007 20:40:21 Olly Betts wrote:>
Post by Olly Betts
Additionally, each engine provides a directory at
/etc/phpPHPVERSION/PHPSAPI/conf.d where 3rd party PHP libraries and
modules can provide additional configuration information.
XXX this second part is not yet true.
It looks like the second part is now mostly true. README.Debian in the
yeah, the webapps policy needs to get sync'd up with the current state of
things. another thing for my debconf todo list :)
Post by Olly Betts
The rationale with this method is that each SAPI can thus be
identically configured with a minimal amount of conffile handling,
but at the same time if you want to have SAPI-specific configuration,
you can just remove the symlink.
Should a package attempt to do anything special in the situation?
Should I be trying to copy xapian.ini into the conf.d for every SAPI
or is it assumed that this is up to the sysadmin if he or she removes
the symlinks?
i would say no, if the admin has done that then they've done so for a reason,
so you shouldn't try and do anything other than dropping the file in the
top-level conf.d.

*however*, there's some discussion now about adding a php5enmod/dismod similar
to apache, see the pkg-php-maint archives if you're interested.
Post by Olly Betts
And is there a recommended way to handle edits made to php.ini by the
currently install version of a package when moving to using conf.d?
I can easily check for the appropriate line and remove it if present,
i would say put the check in a conditional part of your preinst script to only
be done when upgrading from a version less than the next version.


sean

sean
Olly Betts
2007-06-18 17:15:21 UTC
Permalink
Sean,

Thanks for the reply. I've implemented this in xapian-bindings 1.0.1-1
(binary package php5-xapian) which was uploaded last week.
Post by sean finney
*however*, there's some discussion now about adding a php5enmod/dismod
similar to apache, see the pkg-php-maint archives if you're interested.
I couldn't locate the discussion in the archives, either with Google or
by browsing the index pages for the last year. But I'm happy to wait
for something to be decided and then work on support for it.

Cheers,
Olly

P.S. Has "use conf.d rather than modifying php.ini directly" been
considered as a release goal for lenny?
--
To UNSUBSCRIBE, email to debian-webapps-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Raphael Geissert
2007-11-25 00:34:13 UTC
Permalink
Hello Olly,
Post by Olly Betts
Post by sean finney
*however*, there's some discussion now about adding a php5enmod/dismod
similar to apache, see the pkg-php-maint archives if you're interested.
I couldn't locate the discussion in the archives, either with Google or
by browsing the index pages for the last year. But I'm happy to wait
for something to be decided and then work on support for it.
Please check the next pages which contain relevant information:
http://wiki.debian.org/PHP#head-3a3ea90a961ce57ab37e4e4c832448d58e2cf16d
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447826
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447827
http://lists.alioth.debian.org/pipermail/pkg-php-maint/2007-October/003228.html
Post by Olly Betts
P.S. Has "use conf.d rather than modifying php.ini directly" been
considered as a release goal for lenny?
AFAIK, no.
I'll see if I can figure out a way to detect such packages and fill reports
against them.

Sincerely,
--
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
--
To UNSUBSCRIBE, email to debian-webapps-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Continue reading on narkive:
Loading...