LAMP layer
Hi all,
In conjunction with the folks at Wind River I'm currently in the process of putting together a layer to support the traditional LAMP stack, and wanted to solicit some opinions on how this might be structured/named/etc.
I think we have the "L" pretty much covered ;) and we have MySQL in meta-oe (I'm not convinced that's where it should stay, although perhaps it need not be tied to this layer either). So the layer would at the very least be adding Apache and PHP, with the possibility of web-related python and perl recipes being added at a later date.
Some of the other things I'm looking at adding more immediately:
* collectd
* mysql-connector-odbc
* phpMyAdmin
* unixODBC
* xdebug
The question of how this should all be structured is still not fully determined. I'm thinking this ought to be at least one additional layer (i.e. meta-lamp, or some other name), even in the face of the proposed meta- networking, since the number of recipes in the LAMP layer is likely to grow over time and it's a specific set of functionality that people would explicitly select.
I now have updated apache and modphp recipes building and working reasonably well, although further testing will be needed. Initially I'm prepared to maintain these recipes, however if not immediately at some point in the near future it would be good to see a maintainer step forward with more specific knowledge of these particular pieces of software.
Thoughts?
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
W dniu 27.06.2012 16:05, Paul Eggleton pisze:
Quoted 4 lines
In conjunction with the folks at Wind River I'm currently in the process of putting together a layer to support the traditional LAMP stack, and wanted to solicit some opinions on how this might be structured/named/etc.
Great to hear ;)
Quoted 3 lines
I think we have the "L" pretty much covered ;) and we have MySQL in meta-oe (I'm not convinced that's where it should stay, although perhaps it need not be tied to this layer either).
MySQL is at 5.1 version - update to 5.5 would be nice to have.
Quoted 5 lines
So the layer would at the very least be adding Apache and PHP, with the possibility of web-related python and perl recipes being added at a later date.
Some of the other things I'm looking at adding more immediately:
Please add 'php-fpm' into PHP. This gives huge speed improvement compared to classic FastCGI way.
Quoted 33 lines · Paul Eggleton
Hi all,
In conjunction with the folks at Wind River I'm currently in the process of putting together a layer to support the traditional LAMP stack, and wanted to solicit some opinions on how this might be structured/named/etc.
I think we have the "L" pretty much covered ;) and we have MySQL in meta-oe (I'm not convinced that's where it should stay, although perhaps it need not be tied to this layer either). So the layer would at the very least be adding Apache and PHP, with the possibility of web-related python and perl recipes being added at a later date.
Some of the other things I'm looking at adding more immediately:
* collectd
* mysql-connector-odbc
* phpMyAdmin
* unixODBC
* xdebugThe question of how this should all be structured is still not fully determined. I'm thinking this ought to be at least one additional layer (i.e. meta-lamp, or some other name), even in the face of the proposed meta- networking, since the number of recipes in the LAMP layer is likely to grow over time and it's a specific set of functionality that people would explicitly select.
I now have updated apache and modphp recipes building and working reasonably well, although further testing will be needed. Initially I'm prepared to maintain these recipes, however if not immediately at some point in the near future it would be good to see a maintainer step forward with more specific knowledge of these particular pieces of software.
Quoted 6 lines
Thoughts?
Cheers,
Paul
Hi Paul,
I think this is a fantastic idea in general and if I remember correctly someone from Linaro was attempting to do something similar to this the other day - so I can't only be me who would appreciate something like this.
The one issue I have (initially) is why should it be limited to the Apache web server? There are a couple of good web servers out there which lend themselves much more to an embedded style development than (IMO) the bloat that is Apache.
For example:
Lighttpd (already in core)
nginx
Hiawatha (my personal favourite - I have a recipe I already use in conjunction with PHP)
I also remember someone from WindRiver posted recently regarding a meta-networking layer, which I also thought was a great idea if not only for (in my use case) tftp/net-snmp support all rolled up and supported. Maybe this could be a layer with that "section"?
i.e.
meta-networking
meta-webserver (meta-l*mp?)
recipes-*
recipes-*
meta-*
....
....I'm sure you get the idea...
Regards,
Signature · 5 lines
Jack Mitchell ([email protected]) Embedded Systems Engineer http://www.embed.me.uk --
Quoted 4 lines · Jack Mitchell
Lighttpd (already in core)
nginx
Hiawatha (my personal favourite - I have a recipe I already use in conjunction with PHP)
I'd add Cherokee to the list; there is a recipe in meta-oe.
Tomas
Quoted 3 lines · On Wednesday 27 June 2012 16:22:09 Jack Mitchell wrote:
I think this is a fantastic idea in general and if I remember correctly someone from Linaro was attempting to do something similar to this the other day - so I can't only be me who would appreciate something like this.
Indeed, I saw Marcin's earlier thread - at the time I wasn't far enough along to reply unfortunately (was just an item on my todo list), but at least there's interest :)
Quoted 11 lines
The one issue I have (initially) is why should it be limited to the Apache web server? There are a couple of good web servers out there which lend themselves much more to an embedded style development than (IMO) the bloat that is Apache.
For example:
Lighttpd (already in core)
nginx
Hiawatha (my personal favourite - I have a recipe I already use in conjunction with PHP)
I agree Apache is not something you would typically consider to be embedded- friendly, however if you've already got something web-based that is built on top of Apache or relies on functionality that only Apache can provide, and you want to integrate that into an embedded product, then nothing else will really suffice.
However I do think there's scope to include these other alternatives particularly if the layer turns into more of a generic web server layer, but I can't commit to maintaining (specifically, updating and testing) the additional recipes on my own.
Quoted 7 lines
I also remember someone from WindRiver posted recently regarding a meta-networking layer, which I also thought was a great idea if not only for (in my use case) tftp/net-snmp support all rolled up and supported. Maybe this could be a layer with that "section"?
i.e.
Quoted 7 lines
meta-networking
meta-webserver (meta-l*mp?) recipes-* recipes-* meta-* .... ....
Whenever a new layer is introduced there's always the question of where it should be physically located. I worry more about the confusion that multi- level layers cause - particularly when they're named the same thing - than I do about multiple repositories, but I realise others have different viewpoints. If they are in separate repositories there's still nothing stopping them being used together.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 27 lines · Paul Eggleton
Quoted 3 lines · On Wednesday 27 June 2012 16:22:09 Jack Mitchell wrote:
I think this is a fantastic idea in general and if I remember correctly someone from Linaro was attempting to do something similar to this the other day - so I can't only be me who would appreciate something like this.
Indeed, I saw Marcin's earlier thread - at the time I wasn't far enough along to reply unfortunately (was just an item on my todo list), but at least there's interest :)
Quoted 11 lines
The one issue I have (initially) is why should it be limited to the Apache web server? There are a couple of good web servers out there which lend themselves much more to an embedded style development than (IMO) the bloat that is Apache.
For example:
Lighttpd (already in core)
nginx
Hiawatha (my personal favourite - I have a recipe I already use in conjunction with PHP)I agree Apache is not something you would typically consider to be embedded- friendly, however if you've already got something web-based that is built on top of Apache or relies on functionality that only Apache can provide, and you want to integrate that into an embedded product, then nothing else will really suffice.
Quoted 4 lines
However I do think there's scope to include these other alternatives particularly if the layer turns into more of a generic web server layer, but I can't commit to maintaining (specifically, updating and testing) the additional recipes on my own.
I would be happy to contribute the hiawatha recipe (it's just simple cmake job), but I understand your earlier comment on standalone PHP as it is indeed a minefield. I tried to update it some weeks ago and failed miserably.
Possibly just do your part and let people send in patches against the layer as is done with meta-oe?
Quoted 17 lines
Quoted 9 lines
I also remember someone from WindRiver posted recently regarding a meta-networking layer, which I also thought was a great idea if not only for (in my use case) tftp/net-snmp support all rolled up and supported. Maybe this could be a layer with that "section"?
i.e.
Quoted 7 lines
meta-networking
meta-webserver (meta-l*mp?) recipes-* recipes-* meta-* .... ....
Quoted 6 lines
Whenever a new layer is introduced there's always the question of where it should be physically located. I worry more about the confusion that multi- level layers cause - particularly when they're named the same thing - than I do about multiple repositories, but I realise others have different viewpoints. If they are in separate repositories there's still nothing stopping them being used together.
I do agree that layers within layers is a bit confusing, however the earlier proposed meta-networking included having some of the applications in this proposed layer too. If this was instead, then it's fine, but if it's as well then it could get confusing.
A possible compromise could be a git sub-module for meta-lamp inside meta-networking, or at least a file containing the meta-lamp location and highlighting its availability?
Quoted 5 lines
Cheers,
Paul
Quoted 4 lines · On Wednesday 27 June 2012 17:40:44 Jack Mitchell wrote:
I do agree that layers within layers is a bit confusing, however the earlier proposed meta-networking included having some of the applications in this proposed layer too. If this was instead, then it's fine, but if it's as well then it could get confusing.
It's something I've been discussing with Joe MacDonald already. I think it's an either-or situation - the recipes will not need to be in both layers. People who want recipes from either or both layers should be able to include the layers as needed.
Quoted 3 lines
A possible compromise could be a git sub-module for meta-lamp inside meta-networking, or at least a file containing the meta-lamp location and highlighting its availability?
Given the above I think a pointer in the meta-networking README towards the web server layer would be reasonable.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 5 lines · Paul Eggleton
It's something I've been discussing with Joe MacDonald already. I think it's an either-or situation - the recipes will not need to be in both layers. People who want recipes from either or both layers should be able to include the layers as needed.
from my experience of deploying layers for others. Its quite a talk for folks to get it and on top if you have overlapping recipes they are not making life any
easier. if we start using this kind of method, it sure will fume into chaos. I think layers should have some wholeness to them but at the same time they should
be leveraging other layers to get functionality they need.
Quoted 7 lines · On Wednesday 27 June 2012 11:01:09 Khem Raj wrote:
Quoted 4 lines · Paul Eggleton
It's something I've been discussing with Joe MacDonald already. I think it's an either-or situation - the recipes will not need to be in both layers. People who want recipes from either or both layers should be able to include the layers as needed.
Quoted 6 lines
from my experience of deploying layers for others. Its quite a talk for folks to get it and on top if you have overlapping recipes they are not making life any easier. if we start using this kind of method, it sure will fume into chaos. I think layers should have some wholeness to them but at the same time they should be leveraging other layers to get functionality they need.
I agree completely - my intention is not to have any overlapping recipes.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 27 lines · Paul Eggleton
Hi all,
In conjunction with the folks at Wind River I'm currently in the process of putting together a layer to support the traditional LAMP stack, and wanted to solicit some opinions on how this might be structured/named/etc.
I think we have the "L" pretty much covered ;) and we have MySQL in meta-oe (I'm not convinced that's where it should stay, although perhaps it need not be tied to this layer either). So the layer would at the very least be adding Apache and PHP, with the possibility of web-related python and perl recipes being added at a later date.
Some of the other things I'm looking at adding more immediately:
* collectd
* mysql-connector-odbc
* phpMyAdmin
* unixODBC
* xdebugThe question of how this should all be structured is still not fully determined. I'm thinking this ought to be at least one additional layer (i.e. meta-lamp, or some other name), even in the face of the proposed meta- networking, since the number of recipes in the LAMP layer is likely to grow over time and it's a specific set of functionality that people would explicitly select.
Quoted 8 lines
I now have updated apache and modphp recipes building and working reasonably well, although further testing will be needed. Initially I'm prepared to maintain these recipes, however if not immediately at some point in the near future it would be good to see a maintainer step forward with more specific knowledge of these particular pieces of software.
Thoughts?
I think PHP probably is common enough to be part
of meta-oe or core. instead of lamp call it something else may be meta-webservers or something
and more alternatives can also be put in there
Quoted 12 lines
Cheers,
Paul--
Paul Eggleton
Intel Open Source Technology Centre
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Quoted 4 lines · On Wednesday 27 June 2012 08:49:22 Khem Raj wrote:
I think PHP probably is common enough to be part
of meta-oe or core. instead of lamp call it something else may be meta-webservers or something
and more alternatives can also be put in there
I don't know a huge amount about PHP but it appears to me that it can be built either standalone or as an Apache module - we had two separate recipes to build each alternative in OE-classic, and that split persists today - the standalone version is in meta-oe and I'm resurrecting the apache module version (modphp).
I don't think PHP belongs in OE-core - it's not something everyone needs. I'm willing to accept the standalone version might also belong in this layer though particularly if it turns into a more generic web server layer as you're suggesting. I'm not sure I can commit to cleaning up the standalone version though.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre