Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#43468 closed defect (wontfix)

php55 port missing pear variant (or subport?)

Reported by: mp@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: Cc: ryandesign (Ryan Carsten Schmidt), pixilla (Bradley Giesbrecht)
Port: php55

Description

With php5, one could install +pear and get the "pear" command to install custom PEAR packages.

The php55 port seems to be missing this variant. It also does not provide a -pear subport, FWIW.

Is this a bug or what is the recommended way of getting PEAR to work?

Installing pear-... ports is not a solution for the various 3rd party PEAR packages out there.

Change History (7)

comment:1 Changed 10 years ago by mp@…

#34371 asked the same question for the php53 port and was pointed to php5-pear. That, however, only contains config files and not the "pear" command itself.

comment:2 in reply to:  1 Changed 10 years ago by pixilla (Bradley Giesbrecht)

Replying to mp@…:

Installing pear-... ports is not a solution for the various 3rd party PEAR packages out there.

Why are pear-… ports not a solution? If there is a PEAR package you want to install that is not provided by MacPorts please open a "request" ticket.

MacPorts provides pear-… packages rather then the "pear" command line tool so other MacPorts ports can depend on pear-... ports.

If you do not want to use MacPorts pear-… ports to manage your PEAR packages you can install your own pear command using the documentation the PEAR project provides.

Last edited 10 years ago by pixilla (Bradley Giesbrecht) (previous) (diff)

comment:3 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… pixilla@… added
Resolution: wontfix
Status: newclosed

Right, it was a deliberate decision to no longer provide the pear binary to users.

comment:4 Changed 10 years ago by mp@…

Oh, that's bad news.

Sure, it makes sense to be able to provide PEAR packages as ports and to depend upon them.

But, on the other hand, there are so many PEAR packages out there. Many open source projects provide their own PEAR channels and according install instructions, not to mention closed-source (internal) packages folks might use. I don't think it's practical or feasible to re-package all those as ports.

In this situation, not easily having a pear binary at hand when installing one of the newer (php55, for example) ports - as opposed to the "old" php5+pear one - is a bit of unnecessary complexity IMO.

So what's the problem with the binary - is it getting in the way somewhere?

Last edited 10 years ago by mp@… (previous) (diff)

comment:5 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

The problem is that if we provided a pear binary, it would install files into the MacPorts prefix, and we would really prefer if the only way for files to be installed into the MacPorts prefix was by using MacPorts itself. A solution can be for you to install pear manually, to a different prefix, and for you to manage that manually, outside of MacPorts.

comment:6 Changed 10 years ago by mp@…

That's a comprehensible argument. Not what I was hoping for, but thanks anyway :-).

comment:7 Changed 10 years ago by pixilla (Bradley Giesbrecht)

There are pear packages in MacPorts from many pear channels other then pear.php.net. The pear Portfiles are very simple to create.

Run this command to get a list of pear packages and the channels they come from:

$ port cat name:^pear- | grep pear.setup

Regarding private pear channels, in minutes you could create a private pear port targeting your pear channel.

And if you still want your own pear command here is a simple way to get it for yourself:

$ curl -s http://pear.php.net/go-pear.phar > ~/go-pear.phar
$ sudo php ~/go-pear.phar
Note: See TracTickets for help on using tickets.