Need clarification on install procedure

[Scott Haneda]

On Jul 1, 2010, at 10:40 AM, Ryan Schmidt wrote:

> 
> On Jul 1, 2010, at 12:15, Scott Haneda wrote:
> 
>> On Jul 1, 2010, at 6:44 AM, Ryan Schmidt wrote:
>> 
>>> Same for PEAR support: instead, you use the php5 port's +pear variant.
>> 
>> How come if you need MySql support you would do php5-mysql but if you need pear you would do php5 +pear, which seems inconsistent?  I don't care, but to a end user, it would seem more logical to be looking for php5-pear.
> 
> Completely agreed. I'd like things to be consistent and expected, and that's one reason #19091 is still not closed after a year. (It's not done.)
> 
> I would like php5 +pear to become php5-pear. Anybody interested in making that happen should feel free to do so. I personally have not had any interest in PEAR in many years which is why it is not a priority for me.

I personally have never used it myself.  Just now looking at it, what it is, what it does, it does very much seem like it may not have a place in MP's.  It is an entire framework, much like CPAN, which is the entire reason I came to MP's, to get away from that type of situation.

> The other option is for us to say the user should install PEAR manually, and to just remove the pear variant and provide no replacement in MacPorts.

I know this is harsh, but I like this option best, in the name of consistency and end user ease. If you need pear you should hopefully know what you are doing well enough this should not be a barrier.

> The problem with PEAR that I've mentioned before is that like Perl's CPAN and Ruby's Gems, it installs things into the MacPorts prefix, which we don't want software to do. For Perl and to some extend Ruby we chose to overcome this by making individual ports for each module. We could do the same with each bit of software you can get from PEAR. But it would be a big undertaking. I'm not going to be the one to undertake it, but others should feel free to investigate it.

Yes, it seems like a lot of work.  I think the way that p5's is handled is good, and was needed in order to give MP's the momentum, availability, exposure, and usefulness to many.  Outside of that, and as you mentioned, a bit of the Ruby stuff, I am not seeing a compelling reason to deprecate pear in MP's and leave a "stub" port in place that explains this.  Maybe the replaced by type of port would be a good match for this.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *