[php-maint] Re: final php5 changes for etch

Steve Langasek vorlon at debian.org
Sat Oct 21 12:31:06 CEST 2006


Hi Sean,

On Wed, Oct 18, 2006 at 10:10:27PM +0200, sean finney wrote:

> so this is what i'm planning on committing and uploading, probably this
> weekend:

If you have time to upload this weekend, please go ahead.  If you aren't
going to get to it this weekend, please hold off on the upload until the
apache2.2 transition finishes.  I'm expecting that transition to be ready
early to mid next week, which leaves a window for uploading php5 in the next
day or two without disrupting that schedule.

> - the new conf layout

> obviously, the last item is the biggest one.  i spoke a bit about this
> with adam, and i *think* we decided on the following:

> - each sapi is configured with a different --config-scan-files-dir
> - this dir will actually be a symlink to /etc/phpN/conf.d
> - the per-module conffiles will go in /etc/phpN/conf.d

> this way, if the admin wants to customize things on a per-sapi basis,
> they can remove the symlink, do a mkdir, and manage it seperate

> i've committed something to the php5 repository which *should* do this,
> though i haven't got to testing it yet.  really sucks when each little
> change includes a half-hour build :)

> *but* there are two unresolved issues:

> - handling non-purge removal
> - handling previous modifications (extension=foo.so in php.ini)

> for the former, i see two options.  we can (a) not care, in which case
> if the admin removes the package, they will get WARNING level messages
> about not being able to load the module.  or (b) we can have a
> "conf-available" directory which adds/removes symlinks into the main
> conf.d directory during installation/removal.  this would be in line
> with how apache does things.

hmm, I think I fall in the "not care" camp.  I tried to figure out if there
was some way these symlinks could be pointed at something under /usr/share
and then there would be no need to worry about non-purge at all (because no
more conffiles), but I realize users probably want somewhat finer-grained
customization control than "point at /usr/share" / "make your own directory
and copy the config".

> for the latter, we can either (a) not care, which results in WARNING
> messages about duplicate modules, or (b) prune them out of the
> respective config files.

As we discussed on IRC, I would prefer to see these module packages take
responsibility for their own mess, and clean up the old module entries in
php.ini.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/



More information about the pkg-php-maint mailing list