[php-maint] Bug#687307: Fwd: Updating php5 to 5.4.4-5 broke FastCGI setup on my machine

[Ondřej Surý]

Stephan,

thanks for the input.

Just one last question which came to my mind. Would this all be fixed
if we added non-magic type to mime-support (e.g.
http://bugs.debian.org/670945) and reverting the changes done in the
php5-cgi package?

That I think would justify change in the mime-support package. Too
much breakage on every front now.

O.

On Sat, Oct 6, 2012 at 9:51 PM, Stefan Fritsch <sf at debian.org> wrote:
> Hi Ondřej,
>
> I also cannot think of any configuration that would make everyone happy. At
> the moment, I fear this can only be solved by more documentation.
>
> Maybe one could add such a paragraph to the NEWS entry of php5-cgi 5.4.4-5,
> e.g. before "The standard configuration now also..." :
>
>   WARNING: The new configuration may override other configuration
>   directives you may have added locally for the .php extension, for
>   example for FastCGI processing. This behavior is caused by <FilesMatch>
>   configuration sections overriding directives appearing in global server
>   or VirtualHost scope. You should review and test your configuration and
>   verify that your php scripts work as expected.
>
> The README.Debian or the wiki page you are already pointing to should then
> list likely candidates for problematic local configurations, like
> "AddHandler fcgid-script .php". Maybe it could also say, that if all else
> fails and the user is willing to live with the *.php.foo problem, the old
> behavior can be restored by replacing
> etc/apache2/mods-available/php5_cgi.conf with something like
>
>   AddType application/x-httpd-php phtml pht php php3 php4 php5
>   AddType application/x-httpd-php-source phps
>
> to get the old behavior back. What do you think?
>
> This sucks. In hindsight, maybe the mime.types change should have been
> deferred until we ugrade to apache 2.4 and people have to adjust their
> configs anyway. But I think it's too late now to go back. And leaving the
> *.php.foo problem there for yet another release cycle would not have been a
> good solution either.
>
> Cheers,
> Stefan



-- 
Ondřej Surý <ondrej at sury.org>