[php-maint] php 5.3 in sid (was: php 5.3.1 in experimental)
geissert at debian.org
Tue Jan 12 07:52:52 UTC 2010
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.
>> * 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
In both cases I meant a separate *binary* package, just like the many
>> * 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
> 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.
Can the others comment too?
Although I don't think anyone has any objection I don't want to make
any assumption either.
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
More information about the pkg-php-maint