[needs-packaging] php5-embed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
php5 (Debian) |
Fix Released
|
Unknown
|
|||
php5 (Ubuntu) |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
This is a request for a php5-embed package. PHP has multiple "SAPIs", such as standard, cli, cgi and embed. All of these are packaged except embed (as php5, php5-cgi and php5-cli.
To compile the package, configure PHP with
./configure --enable-embed
CVE References
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Deepak Tripathi (gnumonk) wrote : | #1 |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Paul (paul-biggar) wrote : Re: [Bug 191251] Re: Request for php5-embed package | #2 |
It uses the same tar.gz as php5, so it is donwloadable from the same
place, and uses the same licence. The only difference is that it is
configured with --enable-embed.
Thanks,
Paul
On Wed, Apr 16, 2008 at 6:20 AM, Deepak Tripathi
<email address hidden> wrote:
> Hi ,
>
> where you can download and what is the License .
>
>
> Thanks
> Deepak
>
>
>
> --
> Request for php5-embed package
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
Paul Biggar
<email address hidden>
Changed in php5: | |
assignee: | nobody → nvalcarcel |
status: | New → Confirmed |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Nicolas Valcarcel (nvalcarcel) wrote : | #3 |
Can you please give some documentation (a link to) about what is actually embed and/or some tests to check my package please
Changed in php5: | |
assignee: | nvalcarcel → nobody |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Paul (paul-biggar) wrote : Re: [Bug 191251] Re: [needs-packaging] php5-embed | #4 |
Hi Nicolas,
There is a presentation here that explains it:
www.cluesheet.
There is a more detailed guide to programming with it here: http://
I guess to test it you would compile and link a program against it.
Here is a sample program:
http://
Once the package is installed (in /usr/local), you should be able to
compile it with:
gcc -I/usr/
-I/usr/
-L/usr/local/lib -Wl,-R/
I've tested this on Hardy, and it compiles fine. You may need to use
/usr/include instead of /usr/local/include.
Thanks,
Paul
On Wed, Aug 20, 2008 at 10:15 PM, Nicolas Valcárcel (nxvl)
<email address hidden> wrote:
> Can you please give some documentation (a link to) about what is
> actually embed and/or some tests to check my package please
>
> ** Changed in: php5 (Ubuntu)
> Assignee: Nicolas Valcárcel (nxvl) (nvalcarcel) => (unassigned)
>
> --
> [needs-packaging] php5-embed
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
Paul Biggar
<email address hidden>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Nicolas Valcarcel (nvalcarcel) wrote : | #5 |
Ok, thank you for your answer i will test it at night.
On Tue, Aug 26, 2008 at 3:27 AM, Paul <email address hidden> wrote:
> Hi Nicolas,
>
> There is a presentation here that explains it:
> www.cluesheet.
> There is a more detailed guide to programming with it here: http://
>
> I guess to test it you would compile and link a program against it.
> Here is a sample program:
>
> http://
>
> Once the package is installed (in /usr/local), you should be able to
> compile it with:
>
> gcc -I/usr/
> -I/usr/
> -L/usr/local/lib -Wl,-R/
>
> I've tested this on Hardy, and it compiles fine. You may need to use
> /usr/include instead of /usr/local/include.
>
>
> Thanks,
> Paul
>
>
> On Wed, Aug 20, 2008 at 10:15 PM, Nicolas Valcárcel (nxvl)
> <email address hidden> wrote:
>> Can you please give some documentation (a link to) about what is
>> actually embed and/or some tests to check my package please
>>
>> ** Changed in: php5 (Ubuntu)
>> Assignee: Nicolas Valcárcel (nxvl) (nvalcarcel) => (unassigned)
>>
>> --
>> [needs-packaging] php5-embed
>> https:/
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
>
> --
> Paul Biggar
> <email address hidden>
>
> --
> [needs-packaging] php5-embed
> https:/
> You received this bug notification because you are a member of Ubuntu
> Server Team, which is subscribed to php5 in ubuntu.
>
> --
> Ubuntu-server-bugs mailing list
> <email address hidden>
> Modify settings or unsubscribe at: https:/
>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Paul (paul-biggar) wrote : | #6 |
Hi Nicolas,
Have you had any luck with this?
Thanks,
Paul
On Tue, Aug 26, 2008 at 10:37 PM, Nicolas Valcárcel (nxvl)
<email address hidden> wrote:
> Ok, thank you for your answer i will test it at night.
>
> On Tue, Aug 26, 2008 at 3:27 AM, Paul <email address hidden> wrote:
>> Hi Nicolas,
>>
>> There is a presentation here that explains it:
>> www.cluesheet.
>> There is a more detailed guide to programming with it here: http://
>>
>> I guess to test it you would compile and link a program against it.
>> Here is a sample program:
>>
>> http://
>>
>> Once the package is installed (in /usr/local), you should be able to
>> compile it with:
>>
>> gcc -I/usr/
>> -I/usr/
>> -L/usr/local/lib -Wl,-R/
>>
>> I've tested this on Hardy, and it compiles fine. You may need to use
>> /usr/include instead of /usr/local/include.
>>
>>
>> Thanks,
>> Paul
>>
>>
>> On Wed, Aug 20, 2008 at 10:15 PM, Nicolas Valcárcel (nxvl)
>> <email address hidden> wrote:
>>> Can you please give some documentation (a link to) about what is
>>> actually embed and/or some tests to check my package please
>>>
>>> ** Changed in: php5 (Ubuntu)
>>> Assignee: Nicolas Valcárcel (nxvl) (nvalcarcel) => (unassigned)
>>>
>>> --
>>> [needs-packaging] php5-embed
>>> https:/
>>> You received this bug notification because you are a direct subscriber
>>> of the bug.
>>>
>>
>>
>> --
>> Paul Biggar
>> <email address hidden>
>>
>> --
>> [needs-packaging] php5-embed
>> https:/
>> You received this bug notification because you are a member of Ubuntu
>> Server Team, which is subscribed to php5 in ubuntu.
>>
>> --
>> Ubuntu-server-bugs mailing list
>> <email address hidden>
>> Modify settings or unsubscribe at: https:/
>>
>
> --
> [needs-packaging] php5-embed
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
Paul Biggar
<email address hidden>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Erik van Pienbroek (openftd) wrote : | #7 |
- Patch to enable building of the embed SAPI Edit (6.7 KiB, text/plain)
For Debian I've just wrote a patch which enables building of an libphp5-embed package. This patch is published at http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Chuck Short (zulcss) wrote : | #8 |
We wont be doing this in the main php package. It should be split out like php5-imap or php5-suhoshin or php5-suhoshin.
Regards
chuck
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Paul (paul-biggar) wrote : | #9 |
Hi Chuck,
The main php package seems like the only natural place to put it. Can I ask for your reasons for not doing it there?
In case its a misunderstanding, I'll make a case for it. This is a first-class, built-in, configuration option, maintained by the PHP Group. Support, bugs etc all goes through the standard PHP channels.
This isn't an extension/library like imap, or a patch like suhoshin. Its at the same level at php5-cli and php5-cgi.
If this doesn't go into the main php package, where would it go? Any other request would (I presume) be sent back here.
Thanks in advance,
Paul
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Lawrence (lcoffin) wrote : | #10 |
Is this package/feature available somewhere?
Changed in php5 (Debian): | |
status: | Unknown → New |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Julius H. (julius-h) wrote : | #11 |
No package yet? :|
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Ondřej Surý (ondrej) wrote : | #12 |
Speaking here as a member of Debian php maintainers.
I have read mentioned web pages and nothing has convinced me, that this is more then just proof of concept with no real application in the sensible world.
php5 is a language for creating web pages. Embedding language which a horrible design, constantly changes the API, with no common concept, is just a very bad idea. And I hope Ubuntu will never stray and package php5-embed on it's own, since it's not going to happen in Debian(*).
There is a bunch of other programming languages suited for embedding - lua, python, ruby, even perl. Embedding php5 is just wrong. Don't do it.
Ondrej
* - unless current php maintainers all retire and new maintainers will lost their minds, or we are overruled by technical committee in which case I would probably retire as php maintainer
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Paul (paul-biggar) wrote : | #13 |
The debian PHP maintainers are refusing the package this for a
religious reason: that they abhor PHP and believe it should not
spread. I don't believe it is suitable to hold up a package for this
reason. I'm not sure we can force their hand, so perhaps it is time to
start packaging PHP separately in Ubuntu.
On Tue, Feb 9, 2010 at 12:25 AM, Ondřej Surý <email address hidden> wrote:
> Speaking here as a member of Debian php maintainers.
If you all hate PHP, I do not understand why you are the PHP maintainers.
> I have read mentioned web pages and nothing has convinced me, that this
> is more then just proof of concept with no real application in the
> sensible world.
Its a dependency for phc, a compiler/
php5-embed is well tested, and has not changed in four years.
> php5 is a language for creating web pages. Embedding language which a
> horrible design, constantly changes the API, with no common concept, is
> just a very bad idea. And I hope Ubuntu will never stray and package
> php5-embed on it's own, since it's not going to happen in Debian(*).
Please support "horrible design" and "no common concept". I can tell
you the interface has not changed in the four years the debian bug has
been open. "a very bad idea" is a religious opinion.
> There is a bunch of other programming languages suited for embedding -
> lua, python, ruby, even perl. Embedding php5 is just wrong. Don't do it.
This is a religious reason, and surely has no place in this debate.
Should we not package Emacs because the maintainers prefer vim?
> * - unless current php maintainers all retire and new maintainers will
> lost their minds, or we are overruled by technical committee in which
> case I would probably retire as php maintainer
Considering that you are refusing to package part of PHP because you
dislike PHP, I think resignation would be a good idea.
Thanks,
Paul
(phc maintainer)
--
Paul Biggar
<email address hidden>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Ondřej Surý (ondrej) wrote : | #14 |
Paul, please refrain from personal attacks next time.
> If you all hate PHP, I do not understand why you are the PHP maintainers.
This comes naturally when you start to take care of php5 :-).
> The debian PHP maintainers are refusing the package this for a
> religious reason: that they abhor PHP and believe it should not
> spread.
Not true. I believe it should not spread outside it's niche - serving web pages. I am free to do so, since I can decide what I want to support. Packaging is not just simple process of throwing some scripts in debian/ directory, it also means you have to take care of bugreports and that you actually care about quality of the final distribution.
I don't want to argue about quality of php, it's out of topic in this bug, I am sure you can find all references to inconsistent APIs, incompatible changes between releases, bad design decisions, inconsistent function behaviour, etc.
> Considering that you are refusing to package part of PHP because you
> dislike PHP, I think resignation would be a good idea.
Well, feel free to do a QA (I mean real bug testing, not just pushing features you want because you wrote phc) with the massive amount of bugs at http://
We are constantly in lack of manpower.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Paul (paul-biggar) wrote : | #15 |
On Tue, Feb 9, 2010 at 2:51 AM, Ondřej Surý <email address hidden> wrote:
> Paul, please refrain from personal attacks next time.
That was no personal attack, I'm sorry it was taken as such. You
outlined your opinion, which is thst PHP should not spread. I cannot
see how this is compatible with being the PHP debian maintainer.
> The debian PHP maintainers are refusing the package this for a
>> religious reason: that they abhor PHP and believe it should not
>> spread.
>
> Not true. I believe it should not spread outside it's niche - serving
> web pages. I am free to do so, since I can decide what I want to
> support. Packaging is not just simple process of throwing some scripts
> in debian/ directory, it also means you have to take care of bugreports
> and that you actually care about quality of the final distribution.
Those are not the reasons given previously in this (or the debian) bug
reports. I'll quote from the Debian bug report:
"Disgust at the idea of propagating php into other contexts?
We have to put up with php as a language for web apps, but it's a rotten
language whose use should not be encouraged. Or supported beyond what's
necessary."
> I don't want to argue about quality of php, it's out of topic in this
> bug, I am sure you can find all references to inconsistent APIs,
> incompatible changes between releases, bad design decisions,
> inconsistent function behaviour, etc.
I'm talking specifically about the php5-embed package. The flaws of
the PHP language are npt relevant here.
>> Considering that you are refusing to package part of PHP because you
>> dislike PHP, I think resignation would be a good idea.
>
> Well, feel free to do a QA (I mean real bug testing, not just pushing features you want because you wrote phc) with the massive amount of bugs at http://
> We are constantly in lack of manpower.
I am not pushing features. I have hunted down, fixed, provided
patches, and followed through with bug reports for php5-embed,
upstream.
You have a patch, and you are sitting on it because you do not like
PHP, and you have said so yourself at least twice: in this bug report,
and in the debian one.
Thanks,
Paul
--
Paul Biggar
<email address hidden>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Pierre Bourdon (delroth) wrote : | #16 |
I'm currently working on a project which exports a scripting API to ~8 different languages, including PHP.
I can't distribute it correctly to Debian and Ubuntu users as it requires the PHP embed SAPI which is not provided by any packages. I do not like PHP either, but my users asked for PHP scripting support.
Currently, deploying my project requires a custom PHP package. So I'm +1000 with Paul on this issue.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Clint Byrum (clint-fewbar) wrote : | #17 |
Just to weigh in, I think its ridiculous that package maintainers would refuse to enable something that offers no additional security risk, and that users depend on (probably more and more as the language matures).
I'd also like to point out this portion of the Ubuntu code of conduct
"Be considerate. Our work will be used by other people, and we in turn will depend on the work of others. Any decision we take will affect users and colleagues, and we should take those consequences into account when making decisions. Ubuntu has millions of users and thousands of contributors. Even if it's not obvious at the time, our contributions to Ubuntu will impact the work of others. For example, changes to code, infrastructure, policy, documentation and translations during a release may negatively impact others' work."
In this case, I don't think we're considering the users' position, or how this negatively affects PHP by making it hard for users to utilize embedded PHP on our platform. The derision of PHP is also fairly inconsiderate to its developers and users.
Given that large libraries of software are in fact being written in PHP now, its reasonable to think that one may want to embed PHP inside something else.
So, I'd like to reiterate the question as to why this can't be part of the php5 package in main (and, hopefully, Debian)
"... I believe it should not spread outside it's niche - serving web pages. I am free to do so, since I can decide what I want to support. Packaging is not just simple process of throwing some scripts in debian/ directory, it also means you have to take care of bugreports and that you actually care about quality of the final distribution."
Can anyone recommend a solution that allows users in need of embedded php to move forward without adding to the burden of php maintenance? It really does sound as if you, Ondrej, would prefer that users not use PHP at all (whether on the web or not). This is unfortunate, truly.
I don't think parallel maintenance actually helps. If bugs are found in PHP via another package, as Chuck suggested originally, they will still affect the main package, but may never be reported or fixed in it. Parallel maintenance works for something tiny like an imap extension, but this is another entry point to PHP, and so really must ride along with php.
To follow my own suggestion, here is a recommendation for moving forward while this bug remains in limbo:
Paul, until this is resolved, I'd suggest you maintain a patched php5 package in a PPA, at least then you'd have Ubuntu packages available for your users. I'd recommend forming a team on Launchpad as the owner of this PPA, so that anyone who needs to use embedded PHP can apply for membership, contribute, and upload to the PPA. This is actually quite trivial to do, and would definitely provide a path forward, though not a great one.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Paul (paul-biggar) wrote : | #18 |
On Fri, Aug 20, 2010 at 4:43 PM, Clint Byrum <email address hidden> wrote:
> To follow my own suggestion, here is a recommendation for moving forward while this bug remains in limbo:
>
> Paul, until this is resolved, I'd suggest you maintain a patched php5
> package in a PPA, at least then you'd have Ubuntu packages available for
> your users. I'd recommend forming a team on Launchpad as the owner of
> this PPA, so that anyone who needs to use embedded PHP can apply for
> membership, contribute, and upload to the PPA. This is actually quite
> trivial to do, and would definitely provide a path forward, though not a
> great one.
I agree with your points, and I think the PPA is a great suggestion
(one was unaware of up until recently). However, I've moved on from
the maintainership of phc (position vacant!), and so am not in a
position to do this.
(I should point out that during the vacancy I am applying all patches
that past muster to phc, in consultation with their authors, lest I
become a roadblock for someone else's work.)
--
Paul Biggar
<email address hidden>
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Diogo Resende (dresende) wrote : | #19 |
Don't do a PPA! Change your minds and program in lua. What a great language it is... not!
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Ondřej Surý (ondrej) wrote : | #20 |
> In this case, I don't think we're considering the users' position,
> or how this negatively affects PHP by making it hard for users
> to utilize embedded PHP on our platform.
I think that's exactly what we do - we do consider the users' position.
phc is almost only user of this SAPI, which is still marked as experimental
(after almost 4 years and last commit from it's upstream author in 2007).
Also quoting Pierre Joye:
> About embed, I also think it is premature to bring it to a stable
> package. It needs some changes to be useful (for ex. split init
> functions so it can be used with embedded server more efficiently).
> Maybe a good start would be to contribute directly to PHP and add some
> tests for this SAPI. Once we reached a stable state, distros can then
> consider to bring it to their users.
So when considering the users' position to not exposing them to experimental
SAPI with almost zero user base and unstable API, the best consideration would
be to not package the embed SAPI.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Lawrence (lcoffin) wrote : | #21 |
*sigh* Three years after this was first reported, another round of server installs, and still no package.
Ondrej, There are applications that use php embed other than phc -- I need it for plphp -- php for postgresql databases.
Out of curiousity... since I'm not a package maintainer, how much extra time would maintaining a package for this really entail? Are we talking an hour or two a year? Or an extra 100 hours a year? Once you've got the PHP source code unpacked and configured for any of the other SAPIs, it only takes two or three extra commands ('./configure --enable-embed', 'make', 'make install') to actually get the embed library installed on the system. Is it that much more to package that up along with all the other SAPI packages? I'm not asking to be facetious, I'm just curious if it really is a ton of extra time to maintain an extra package like this or not.
---Lawrence
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Kari Asikainen (kari-asikainen) wrote : | #22 |
Stumbled on this one today when a developer requested PHP::Interpreter install to Perl to do testing if php functions can be called from Perl and found out that to do this in Debian I have to create custom php5-package. And for reasons that are beyond my understanding. In programming languages (as well as in text editors etc.) you should not limit the users choice, even if you think those choices are wrong.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Nikola Petkanski (nikola.petkanski) wrote : | #23 |
I've just tried to install my own application on another computer and found out that I need to download the source code of the php project and compile it, because one person think that he is in charge of limiting users decision?!
The php5-embed package is a must imho. Whether it is within the main one is irrelevant. We need it.
Having one application to support is one, but having a public php-embed PPA and a custom application relying on it is different. You are restricting the developers and make installing custom applications harder for normal users.
Please, reconsider your position as it's wrong.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Emmett Keyser (ekeyser) wrote : | #24 |
#17 agree
Ondřej Surý I feel you're out of line not just personally but with respect to the CoC.
I realize you have your reasons but while you may not see many requests for php-embed that doesn't necessarily mean no one wants it. What it might mean is that no one wants to expose themselves to your abrasiveness.
If you have feelings against php that's one thing but as maintainer of php for Debian it seems you are in conflict of interest with the php community at large.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Dan Libby (dan-libby) wrote : | #25 |
As a PHP and PHC user, I also request that php-embed be added.
PHC is a useful tool for enabling high performance PHP code. High traffic, high availability sites such as my client's are always looking for ways to squeeze out more performance from their code, and PHC provides a good option for that. ( Thank-you Paul! )
I would love to be able to do "apt-get install phc" and have it "just work". I feel that debian and ubuntu are doing a dis-service to Paul's project, its users, those that have commented in this thread, and others, by refusing to apply a simple patch that has been contributed years ago. I believe that not having a simple install option for php-embed has negatively affected PHC's adoption and widespread use.
With regards to PHP's merits, I migrated to it from C in 1999. I found it to be very easy for a C developer to learn, and much faster and easier to develop applications. I have also used python, perl, java, and other languages but always return to PHP when I need to build something quickly due to its flexibility, expressiveness, library, documentation, wide availability of examples, and so on. In my experience, it is entirely possible to build complex applications in PHP with similar defect rates to java or other applications.
Maintainers: Please put your personal biases aside and re-consider adding this package.
respectfully,
Dan Libby
NOT a member of either PHP or PHC dev teams.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
roberto (roberto-unbit) wrote : | #26 |
Recently the uWSGI project got php support via libphp (php-embed)
http://
Without proper php-embed support the uwsgi php plugin cannot be included in debian/ubuntu
Some news about it ?
RedHat based distros (centos, fedora...) already include that.
Changed in php5 (Debian): | |
status: | New → Fix Released |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Thomas Ward (teward) wrote : | #27 |
According to this changelog excerpt from the current package in Quantal (as part of 5.4.6-1ubuntu1), the embed SAPI was enabled in that update:
php5 (5.4.1-1) unstable; urgency=low
* Imported Upstream version 5.4.1
+ Fixed insufficient validating of upload name leading to corrupted
$_FILES indices). (CVE-2012-1172).
+ Add open_basedir checks to readline_
readline_
+ Add Apache 2.4 support (.deb package in experimental comming soon)
+ Added debug info handler to DOM objects.
* Remove Breaks: on php applications on maintainer requests:
+ simplesamlphp
+ php-horde-auth
* Add better configuration snippet for CGI (Closes: #571795)
* Update a description of PHP language based on the text from upstream
web page (http://
* Enable embed SAPI (Closes: #380731)
* Add lintian override for libphp5-embed: embedded-library
usr/
* Add ldconfig to libphp5-
* Fix #EXTRA# processing for SAPIs (extra ; at the end of sed cmd)
-- Ondrej Surý <email address hidden> Thu, 03 May 2012 13:29:07 +0200
I'm going to mark this one as "Fix Released" now that this was fixed in Quantal, as it is part of 5.4.6-1ubuntu1.
Changed in php5 (Ubuntu): | |
status: | Confirmed → Fix Released |
Hi ,
where you can download and what is the License .
Thanks
Deepak