[php-maint] php 5.3 in sid (was: php 5.3.1 in experimental)

[Raphael Geissert]

2010/1/12 Ondřej Surý <ondrej at debian.org>:
> On Tue, Jan 12, 2010 at 08:11, Raphael Geissert <geissert at debian.org> wrote:
>> 2010/1/11 Ondřej Surý <ondrej at debian.org>:
>>>
>>> I am all for it. We just need to cherry-pick all changes made to 5.2.x
>>> (debian-sid) branch meanwhile, so we don't have regressions.
>>>
>>
>> Ok, since nobody has raised any objection, let's do it.
>>
>> TODO:
>>
>> * Merge latest .12 commits into -experimental branch
>>
>> -> Done on my local repository.
>
> Already done that and 5.3.1-2 contains all relevant changes since we
> split the branch. I did some serious cherry picking yesterday. Sorry,
> if this breaks your local repository.

I made some other changes to the sid branch, but the commits
notifications mailing list still requires one to be subscribed to
allow posting so the notifications were not sent (and I am subscribed,
but not with this address).

>
>> * Shall we enable Enchant?
>>
>> -> I'd say yes. I've already done it on my local repository, as a
>> separate package because it pulls in libenchant, libaspell,
>> libhunspell, libvoikko, libdbus, glib, etc.
>
> Yes, separate package.
>
>> * Shall we enable intl?
>>
>> -> I'd say yes, but am not sure whether it should be done as a
>> separate package or not.
>> Things to take into consideration: it adds a dependency on, at least,
>> libidna, Conflicts (either at dpkg or extensions manager level -- I'd
>> prefer to handle it at the latter level) php5-idn. Should probably be
>> packaged separately.
>
> Agree, we should not put too many eggs in one basket. We should rather
> expect huge amount of bug reports, if they will not come...better for
> us.

In both cases I meant a separate *binary* package, just like the many
other extensions.

>
>> * Send "bits from..." mail
>>
>> -> To mention:
>> - Migration to 5.3
>> - Deprecation of # comments
>> - short_open_tags (see below)
>> - switch to extensions manager
>> - Invite new contributors? help with the BTS would be a good start.
>> - What else? (I'm surely forgetting something)
>
> Switch to automake (>= 1.11)? It can affect packages using php5-dev.

Right, although this should easily be detected by archive-wide rebuilds.

>>
>> * What to do with short_open_tags?
>>
>> -> Status:
>> - The default value in the code is On, but both the development and
>> production php.inis default to Off.
>> - Many php apps in Debian still use short_open_tags.
>>  + But it can now be enabled at runtime, but still requires reporting
>> it to the apps that use it.
>
> I think we should enable it back. Correct way would be to report
> "deprecated" warning (DEBUG level) to errorlog and disable it only
> after some time.

Can you work on a patch to add the E_DEPRECATED warning when a script
requires short_open_tags?

>
> What we can do is to add this to NEWS.Debian/README.Debian for squeezy
> and disable short open tags for squeezy+1.

I'm ok with that as long as a warning is added.

>> * Hardening?
>>
>> -> I would like to use the hardening-wrapper and enable:
>> + DEB_BUILD_HARDENING_STACKPROTECTOR
>> + DEB_BUILD_HARDENING_RELRO
>> + DEB_BUILD_HARDENING_BINDNOW
>> + DEB_BUILD_HARDENING_FORTIFY
>> + DEB_BUILD_HARDENING_FORMAT
>>
>> None of them should cause any trouble and STACKPROTECTOR complements
>> suhosin (which works at the Zend memory manager level, not libc's).
>> Only the stack protector and bind now options introduce a minor
>> performance penalty. The latter should not be a issue as it only
>> affects the start of php, and the former is not big deal as suhosin is
>> the one introducing the major performance penalty.
>
> Ack.

Perfect.

Can the others comment too?
Although I don't think anyone has any objection I don't want to make
any assumption either.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net