Re: [aur-general] RFC on the location of PHP "binaries"

2014-03-08 Thread Jeremy Audet
Thanks for the clarification. The ".phar" extension will effectively put all PHP apps in their own namespace, and that seems like a good conflict-avoidance mechanism to me. (Of course, other folks are free to disagree.) --Jeremy

Re: [aur-general] RFC on the location of PHP "binaries"

2014-03-08 Thread Attila Bukor
On 03/06/2014 05:07 AM, Jeremy Audet wrote: In case anyone is interested, since we've received no answer, we've decided with /usr/share/webapps/bin/ So long as this solution interoperates nicely with web applications written with other frameworks (e.g. Flask, Django, Rails), then I trust your

Re: [aur-general] RFC on the location of PHP "binaries"

2014-03-05 Thread Jeremy Audet
> In case anyone is interested, since we've received no answer, we've decided > with /usr/share/webapps/bin/ So long as this solution interoperates nicely with web applications written with other frameworks (e.g. Flask, Django, Rails), then I trust your judgment. --Jeremy

Re: [aur-general] RFC on the location of PHP "binaries"

2014-03-03 Thread Attila Bukor
Hey guys, In case anyone is interested, since we've received no answer, we've decided with /usr/share/webapps/bin/ Cheers, Attila On 02/28/2014 02:35 PM, Attila Bukor wrote: Hey guys, I'm the maintainer of the phpunit[1] package and I've talked about my idea with Dylan Ferris, maintainer of t

[aur-general] RFC on the location of PHP "binaries"

2014-02-28 Thread Attila Bukor
Hey guys, I'm the maintainer of the phpunit[1] package and I've talked about my idea with Dylan Ferris, maintainer of the php-composer[2] package. The idea is that we should find a standard place for PHAR's which are installed by pacman instead of PEAR. Of course it's obvious that we should omit