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.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
