php5

[Ryan Schmidt]

On Aug 20, 2009, at 13:19, Scott Haneda wrote:

>>> There seems to be a wholly new way of dealing with php, where do  
>>> I find out more about this?
>>
>> Do you mean the new php5 module ports I've been adding in #19091?
>
> I suspect so. I just read it.
>
>
>> I've added a php5-imap port, but haven't yet removed imap  
>> functionality from the php5 port. At least, I didn't think I had  
>> committed that yet.
>
> Excuse any spelling or brevity, I am mobile.

You were quite loquacious. :)


> So apparently there is now a way in php to add modules or features  
> without a recompile. I like this for many reasons. Namely, adding  
> something has less risk to mess up php, since you are not touching  
> it. Is that correct?

Correct, you're not touching the php5 port when you add php5 module  
ports.


> No more waits to rebuilt the whole kit?

Correct. By removing a lot of baggage from the php5 port into module  
ports, the php5 port itself will be quicker to install, and the  
module ports will each be quick to build as well, and if I need to  
make a fix to one module, you'll only have to upgrade that one  
module, not the whole of php5.


> So I ran port upgrade php5 +imap and restarted apache. I still did  
> not have imap. More curious is you can see my installed line above  
> which shows the imap variant in place. Any ideas?

My machines have php5 portfiles in the middle of this transition so I  
have not had a chance to revert to the currently-available version to  
test its imap functionality. I did test the php5-imap port and it  
does provide the imap function you were missing.


> I then just ran port instal php5-imap and php5-mcrypt. I did this  
> on two macines. Both now have imap.

Great!


> One asked me to delete a line about a path.

The message is only printed if the erroneous line is present in the  
php.ini.


> Maybe better to suggest commenting the line.

Perhaps. But there shouldn't be a need to reinstate the line.


> But also, why can't ports just do that for me, or are there risks?

I don't think ports should modify user config files. If there are any  
ports that do so, there aren't many.


> What I am not understanding is why a port installed | grep php  
> shows me the same lines as above in my OP.
>
> I would think that with this new method it would just show php5 and  
> no variants. It would list the other installs that are seperate  
> ports, but doesn't the php5+foo+bar style installed list go away  
> and I should see:
> php5
> php5-whatever
> ...

The variants have been kept in the php5 port as stubs for now. If you  
select them, they advise you to install the separate module ports  
instead. This is so that users upgrading from the previous  
"monolithic" php5 port will not suddenly lose a lot of features they  
wanted and not know how to get them back.

This is not entirely successful, though. I'm not only moving variants  
to module ports; I'm also moving some features that were previously  
always-on, and users get no notification of this, other than certain  
PHP functions no longer being available. I might have rethink this  
lack of notification, and remove all the stub variants and have php5  
always print a message after install advising users to view the  
selection of module ports and install needed ones.


> What are you suggestions for getting my systems cleaned and using  
> entirely this new port group split port method?
>
> I guess just uninstall and run:
> port install php5
> port install php5-whatever-I-need

The split is not completed yet. As you see in #19091 I have made many  
module ports, like php5-imap, whose corresponding variants remain in  
php5. I have a php5 portfile with many changes in my working copy  
that still needs some more testing and changes before I can commit  
it. That will complete round 2 of refactoring. Then there will be a  
3rd round of factoring out the last few module ports. The final round  
will be making separate ports for the SAPIs (apache, fastcgi). And  
then I have to figure out what in the world I'm going to do with php5- 
devel.

When a new version of the php5 port is made available to you, simple  
"port upgrade php5". If you have selected any variants that are now  
stubs, you'll be informed of what new module ports you should install  
to get the same functionality. You can leave php5 installed with  
those stub variants, or you can uninstall php5 and install it without  
them. Eventually the stub variants will be removed.


> Last question. On a production server, live, serving real hosts.  
> Say I need to update from php5.x to 5.3.x. It is also in the same  
> state as my OP. Can I uninstall, and as long as I don't restart  
> apache, it would still run in memory.
>
> I then do my install work, then restart apache, and the new version  
> loads. I just want to make sure I can safely understand how to do  
> in place upgrades with no downtime.

I would assume that's true, but I haven't tested it to the point that  
I would feel comfortable assuring you of that. You should test it  
yourself on another system first.


> I take it there is a mandated restart of apache for every php5-* I  
> add in?

I believe so but you can try it out.


> Is there a php5-server port that would depend on a basic set of  
> these php5-*'s so I can get a pretty good development or server  
> install running without thinking much?
>
> I was thinking mysql, gd, upload progress bar, mcrypt, zip  
> compression, sqlite, imap, tidy, spell, snmp, and probably a few  
> others, like postgress would cover it.

No, I have no plans for that. I feel you are best able to specify  
what PHP features you need, so you just need to install the  
corresponding ports.