Moving forward with php

[sean finney]

hey,

(note that i'm cc'ing this to debian-webapps, to get a slightly wider
audience for some of the issues)


so, now that the die is pretty much cast for php in etch, and modulo the
MOPB things are fairly stable, so let's start talking about the future.
below is a random collection of stuff that i'd like to bring up for
discussion.


-- php4 --

first things first, i want to bring up the topic of dropping php4. i've
been putting off bringing this up for quite a while, and in the meantime
it seems the folks in ubuntu have gone through a similar thought process
and php4 is removed from feisty.

i'm not saying we need to do this now, but i think it would be in our
best interests to have it removed before lenny is released, and want to
get people at least thinking about it now.


-- new upstream versions --

for those who haven't been paying close attention, we've already had to
branch off for etch due to unrelated issues (with libgd2 iirc), so
there's nothing holding us back from getting the latest and greatest
from upstream.

unless someone beats me to it, i'll probably do this over the weekend.


-- pear, pecl, and php policy --

afaik the pear/pecl situation is still really messy wrt debian php
library/extension packages vs locally installed extensions. it's been
so long that i don't even remember what was recommended in the php
policy draft, nor do i remember what was and was not implemented.

this needs revisiting, and ideally some consensus/reminders on what
needs to be done.


-- misc packaging details --

does anyone mind if i drop the home-rolled patch system in favor of
something a little more useful? i've heard a lot of good talk about
quilt lately and would be interested in trying that out, but if there
are strongly formed opinions for using dpatch or something else (or
nothing else) i'm open to hearing them.


-- anything else ? --



sean

[Martin Lohmeier]

Post by sean finney
-- pear, pecl, and php policy --
afaik the pear/pecl situation is still really messy wrt debian php
library/extension packages vs locally installed extensions. it's been
so long that i don't even remember what was recommended in the php
policy draft, nor do i remember what was and was not implemented.
this needs revisiting, and ideally some consensus/reminders on what
needs to be done.

Hey,

the issue of how to deal with pear packages which are installed local
has also been on my mind. When finishing the adoption of the pear
packages this will be one topic I'll deal with. Since I use the pear
command in debian/rules I could add a test to see if a local version of
the package is already installed...or something like this.

bye, Martin

[Steve Langasek]

Post by Martin Lohmeier

Post by sean finney
-- pear, pecl, and php policy --
afaik the pear/pecl situation is still really messy wrt debian php
library/extension packages vs locally installed extensions. it's been
so long that i don't even remember what was recommended in the php
policy draft, nor do i remember what was and was not implemented.
this needs revisiting, and ideally some consensus/reminders on what
needs to be done.

the issue of how to deal with pear packages which are installed local
has also been on my mind. When finishing the adoption of the pear
packages this will be one topic I'll deal with. Since I use the pear
command in debian/rules I could add a test to see if a local version of
the package is already installed...or something like this.

I don't follow, what does debian/rules have to do with the management of the
packages?

Do we have the bug fixed yet where pear install will try to write to
/usr instead of to /usr/local? Do we have a sensible built-in path in php5
that would support installing pear extensions to /usr/local? How about for
pecl?

[sean finney]

hey steve,

Post by Steve Langasek
Do we have the bug fixed yet where pear install will try to write to
/usr instead of to /usr/local? Do we have a sensible built-in path in php5
that would support installing pear extensions to /usr/local? How about for
pecl?

we don't, afaik, and this is to what i was alluding.


sean

[Ondrej Sury]

-- php4 --
I would love to drop php4, we just must prepare upgrade path.

-- new upstream versions --
I suggest we wait for 5.2.2.

-- misc packaging details --
+1 for quilt

I would even think about using cdbs.

Ondrej

[Stephen Gran]

This one time, at band camp, sean finney said:

Disclaimer: I'm not now sponsoring or maintaining any apps that really
are affected by this policy discussion, but count me as an interested
consumer.

Post by sean finney
-- php4 --
first things first, i want to bring up the topic of dropping php4.

Fully agreed. I just finished a migration of several hundred customer
websites to new hardware, and in the process, we made the decision to
leave php4 behind. One website broke (trivial forward port - about a 10
line patch) and one cronjob broke because it called php4 directly. I
understand other people's experience may be different, but mine so far
is that the vast majority of code out there will run on php5 with little
or no changes.

Post by sean finney
-- pear, pecl, and php policy --
afaik the pear/pecl situation is still really messy wrt debian php
library/extension packages vs locally installed extensions.

Yes, I ran into this one time, and although I would have to look at my
notes to remember all the details, it looked like the search path for
extensions was almost an either/or. Painful.

Post by sean finney
-- misc packaging details --
does anyone mind if i drop the home-rolled patch system in favor of
something a little more useful?

Quilt and dpatch are both great. quilt is a little cleverer than dpatch
(allows for arbitrary comment styles at the tops of patches, can do -p0
or -p1 without issue), but both are fine tools.

I'd also love to see another webapps meetup at Debconf, if people think
they're interested.

[Steve Langasek]

Post by sean finney
-- php4 --
first things first, i want to bring up the topic of dropping php4. i've
been putting off bringing this up for quite a while, and in the meantime
it seems the folks in ubuntu have gone through a similar thought process
and php4 is removed from feisty.
i'm not saying we need to do this now, but i think it would be in our
best interests to have it removed before lenny is released, and want to
get people at least thinking about it now.

Sounds like a plan to me.

I would suggest putting together a list of packages that depend on php4 and
contacting the maintainers immediately after the etch release, specifying a
window of time they'll have to fix their packages before php4 will be
dropped.

Post by sean finney
-- new upstream versions --
for those who haven't been paying close attention, we've already had to
branch off for etch due to unrelated issues (with libgd2 iirc), so
there's nothing holding us back from getting the latest and greatest
from upstream.
unless someone beats me to it, i'll probably do this over the weekend.

No objections.

Post by sean finney
-- misc packaging details --
does anyone mind if i drop the home-rolled patch system in favor of
something a little more useful? i've heard a lot of good talk about
quilt lately and would be interested in trying that out, but if there
are strongly formed opinions for using dpatch or something else (or
nothing else) i'm open to hearing them.

I have strongly formed opinions *against* using dpatch. But quilt is ok. :)

[Andrew McMillan]

Post by sean finney
-- php4 --
first things first, i want to bring up the topic of dropping php4. i've
been putting off bringing this up for quite a while, and in the meantime
it seems the folks in ubuntu have gone through a similar thought process
and php4 is removed from feisty.
i'm not saying we need to do this now, but i think it would be in our
best interests to have it removed before lenny is released, and want to
get people at least thinking about it now.

Hi Sean,

It is good to have warning that this is likely to happen. I have only
recently switched to PHP5 for my development environment, and have just
been bitten by the change in the behaviour of '=' with objects.

We have many PHP based sites, some were written with PHP3, most with
PHP4, and newer ones are being written with PHP5. Given that Sarge did
not have PHP5 (at all) and many production websites will have been
written to operate on a stable release it has only been recently that we
have been able to switch to PHP5 development, with the expectation of
using Etch availability for the production environment.

So, if Etch is to be the first release to include PHP5, should it also
be the last to include PHP4? Should we really be looking to immediately
remove PHP4 support? I guess if Lenny is not to be released until 2009
or so then it should definitely be excluded, but if it is released in
2008 perhaps it could still be included.

The situation is different for Ubuntu, which has a much faster release
cycle, so will have had several releases which included PHP5, before
dropping PHP4 support.

Regards,
Andrew McMillan.

-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: [phone] MOB: +64(272)DEBIAN OFFICE: [phone]
Powering the .NZ namespace with Open Source Software
-------------------------------------------------------------------------