You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an end-user
I want php7-mapnik available in PECL,
so I may easily install it with a one liner.
Feasibility
Mapnik requires a tall stack of dependencies that can be hit or miss in repos. While availability has continuously improved, it's still very common to compile from source code. Does it make sense to package the extension when its main dependency is often compiled itself?
The project may need to be renamed and relicensed (PHP License 3.0.1) to comply with PECL standards...
Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"
...and...
We strongly encourage contributors to choose the PHP License 3.01 for their extensions, in order to avoid possible troubles for end-users of the extension.
Todo
Reach out to pecl-dev mailing list. Inquire about license and project name.
Research packaging a C++ extension... Pyrus, pickle, package.xml, etc.
The text was updated successfully, but these errors were encountered:
As an end-user
I want php7-mapnik available in PECL,
so I may easily install it with a one liner.
Feasibility
Mapnik requires a tall stack of dependencies that can be hit or miss in repos. While availability has continuously improved, it's still very common to compile from source code. Does it make sense to package the extension when its main dependency is often compiled itself?
The project may need to be renamed and relicensed (PHP License 3.0.1) to comply with PECL standards...
...and...
Todo
The text was updated successfully, but these errors were encountered: