OVH Cloud OVH Cloud

[gentoo-user-fr] dev-php/php versus dev-lang/php

8 réponses
Avatar
Christophe Garault
Bonjour,

Une bonne âme portée sur le php pourrait-elle me dire la différence
entre les php fournis par dev-lang et dev-php? J'avoue que je commence à
avoir une joyeuse pagaille avec des blocages de partout (lors des
"emerge -pvuDt world" bien sur, sinon tout fonctionne bien) et des
vélléités d'installation de php5 par certains paquets ce que je ne
souhaite pas. Je vais donc devoir mettre à niveau mon package.mask mais
comme je n'y connais pas grand chose dans ce langage, j'aurais souhaité
avoir votre avis. A la limite et pour l'usage que j'en ai, je me
satisferai bien d'un bête mod_php. ;)
Merci d'avance.

--
Et sous les vieux haubans rongés de lente usure,
Poulies aux yeux crevés sur l'infini perdu,
Témoins momifiés des hommes disparus,
Quel dieu féroce a pétrifié dans vos membrures
Les fantômes railleurs de vos orgueils vaincus.
- Anita Conti.
--
gentoo-user-fr@gentoo.org mailing list

8 réponses

Avatar
Fabrice Delliaux
Christophe Garault a écrit :
Une bonne âme portée sur le php pourrait-elle me dire la différence
entre les php fournis par dev-lang et dev-php?



Dans la catégorie dev-lang, ce sont des nouveaux ebuilds permettant
d'installer php4 et php5 en parallèle sur le même système.

Voir la GWN du 5 septembre dernier :
http://www.gentoo.org/news/fr/gwn/20050905-newsletter.xml
paragraphe : Support simultané de PHP4/PHP5 sur Gentoo

A terme, la catégorie dev-php ne sera plus supportée, et disparaîtra.

Voir la GWN du 30 janvier dernier :
http://www.gentoo.org/news/fr/gwn/20060130-newsletter.xml
paragraphe : Réunion de janvier du groupe PHP

Je te conseille vivement de migrer vers la catégorie dev-lang.
--
mailing list
Avatar
Yoann Pannier
Fabrice Delliaux wrote, On 02/16/2006 11:46 PM:
A terme, la catégorie dev-php ne sera plus supportée, et disparaîtra.



D'après ce qu'on peut lire en se baladant sur le Trac de l'equipe PHP
[1], dev-php devrait déjà avoir été masqué (pour 3 mois avant de
disparaitre).

Et si on regarde les versions de PHP4 disponibles, on voit que dev-php
s'arrete a 4.4.0, alors que dans dev-lang on trouve la 4.4.1. PHP5 quant
à lui n'existe même pas dans dev-php.

[1] http://svn.gnqs.org/projects/gentoo-php-overlay/

Je te conseille vivement de migrer vers la catégorie dev-lang.



En suivant http://www.gentoo.org/proj/en/php/php-upgrading.xml

--
Yoann Pannier
--
mailing list
Avatar
Christophe Garault
Fabrice Delliaux a écrit :

Je te conseille vivement de migrer vers la catégorie dev-lang.




Merci à tous les 2 pour ces infos. Je suis pourtant un lecteur assidu de
la GWN mais il faut croire que le php n'est pas ma tasse de thé.

Bon w-e à tous.

--
Christophe Garault


--
mailing list
Avatar
Christophe Garault
philippe a écrit :

Salut à tous,

je me permet de continuer ce post car j'ai suivi ce tuto
(/http://www.gentoo.org/proj/en/php/php4-php5-configuration.xml/) en
prenant l'alternative 1.



Tiens? Peut-on te demander pourquoi Php en CGI et pas en module? Ca
m'intrigue! ;)

Donc si vous avez des propositions pour m'éviter cela .??



Je ne sais pas trop car je n'ai pas vraiment le temps de regarder les
ebuilds en question, mais est-ce que l'install de php-toolkit n'aiderait
pas?

A tout hasard...

--
Et sous les vieux haubans rongés de lente usure,
Poulies aux yeux crevés sur l'infini perdu,
Témoins momifiés des hommes disparus,
Quel dieu féroce a pétrifié dans vos membrures
Les fantômes railleurs de vos orgueils vaincus.
- Anita Conti.
--
mailing list
Avatar
philippe
Salut,

Christophe a écrit :



Tiens? Peut-on te demander pourquoi Php en CGI et pas en module? Ca
m'intrigue! ;)



merci pour ta réponse/question mais tu me poses une colle, etant donné que
je ne connais pas la différence !?
En fait tout a commencé ou des packets bloqués ma Mise A Jour:
[blocks B ] dev-php/PEAR-Archive_Tar (is blocking
dev-php/PEAR-PEAR-1.3.6-r4)
[blocks B ] dev-php/PEAR-Console_Getopt (is blocking
dev-php/PEAR-PEAR-1.3.6-r4)
[blocks B ] dev-php/mod_php (is blocking dev-lang/php-5.0.5-r5)
[blocks B ] dev-php/php (is blocking dev-lang/php-5.0.5-r5)
[blocks B ] dev-php/PEAR-XML_RPC (is blocking
dev-php/PEAR-PEAR-1.3.6-r4)
[blocks B ] <dev-php/PEAR-PEAR-1.3.6-r2 (is blocking
dev-php/PEAR-PEAR-1.3.6-r4)
[blocks B ] dev-php/mod_php (is blocking dev-php/PEAR-PEAR-1.3.6-r4)
[blocks B ] dev-php/php (is blocking dev-php/PEAR-PEAR-1.3.6-r4)

en cherchant j'ai trouvé qu' ils dépendaient essentiellement du soft
"Horde"; j'ai donc désinstallé ces packets mais

[blocks B ] dev-php/mod_php (is blocking dev-lang/php-5.0.5-r5)
[blocks B ] dev-php/php (is blocking dev-lang/php-5.0.5-r5)
[blocks B ] dev-php/mod_php (is blocking dev-php/PEAR-PEAR-1.3.6-r4)
[blocks B ] dev-php/php (is blocking dev-php/PEAR-PEAR-1.3.6-r4)

continuaient à bloquer meme à la désinstallation. C'est de la ou j'ai
cherché une solution (google, forum, vous etc........) et en voyant les GWN
je me suis dit, soyons fou....... un peu à la barbare je le reconnait,
"sachant très bien que portage proposera bientot que du php5".
Je me suis lancé sur l'alternative 1 et apres modification de fichiers
package.mask, vhost apache, réinstallation php4 et php5, j'ai tout
retrouvé. ainsi je n'ai pas essayé les autres solutions.
Je me suis documentés ici :

http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/CommonQuestions
http://www.gentoo.org/proj/en/php/php4-php5-configuration.xml
http://forums.gentoo.org/viewtopic-t-425999-highlight-php.html
http://svn.gnqs.org/projects/gentoo-php-overlay/

Mais cela n'a pas suffit vu qu'il tourne en boucle.
Voila peut-etre que cela pourra répondre en partie à ta question. A moi
maintenant de comprendre la difference entre Php en CGI ou modules.

Je ne sais pas trop car je n'ai pas vraiment le temps de regarder les
ebuilds en question, mais est-ce que l'install de php-toolkit n'aiderait
pas?



Egalement je n'utilise pas php-toolkit, je ne sais pas à quoi ça sert? je
vais regarder de ce pas. en revanche si tu as des conseils à me donner
là-dessus je suis preneur.....

A bientot

Philippe




From: "Christophe Garault"


philippe a écrit :

> Salut à tous,
>
> je me permet de continuer ce post car j'ai suivi ce tuto
> (/http://www.gentoo.org/proj/en/php/php4-php5-configuration.xml/) en
> prenant l'alternative 1.


> Donc si vous avez des propositions pour m'éviter cela .??

Je ne sais pas trop car je n'ai pas vraiment le temps de regarder les
ebuilds en question, mais est-ce que l'install de php-toolkit n'aiderait
pas?

A tout hasard...

--
Et sous les vieux haubans rongés de lente usure,
Poulies aux yeux crevés sur l'infini perdu,
Témoins momifiés des hommes disparus,
Quel dieu féroce a pétrifié dans vos membrures
Les fantômes railleurs de vos orgueils vaincus.
- Anita Conti.
--
mailing list





--
mailing list
Avatar
Yannick Loiseau
Salut

A moi
maintenant de comprendre la difference entre Php en CGI ou modules.



C'est pareil que pour mod_perl ou mod_python... :)

En gros, en 'cgi', t'as un interpréteur Php "standalone", qui peux
executer tes scripts depuis la ligne de commance. C'est necessaire si tu
veux faire des programmes indépendant, avec une GUI en php-gtk par ex.
Si t'utilise ca pour faire une applie web, elle est executée comme CGI,
c'est a dire que apache lance cet interpreteur en sous-process a chaque
fois qu'il doit afficher une page (un cgi peut etre n'importe quel
executable, meme en C ou en bash si tu veux). C'est necessaire pour
faire une appli web avec un autre serveur qu'apache.

Le module (mod_php) permet d'executer du php directement dans Apache,
sans lancer l'interpreteur en sous process. C'est beaucoup plus
efficace, mais ca marche que dans apache (pas d'autre serveur web, pas
de ligne de commande)

Je sais plus pour php, mais l'execution en modules permet en général (en
tout cas pour python sur, et il me semble aussi pour perl) d'avoir acces
à des "truc" interne d'apache, alors que le CGI ne dispose que des
variables standard du standard CGI... Les fonctionnalités sont donc un
peu plus limitées, mais encore une fois, tu te limite dans ce cas a apache.

Ca depend donc de l'utilisation que tu veux en faire. Si t'es sous
apache et que tu veux uniquement faire des applis web, le module est
suffisant, et meme recommandé.
--
mailing list
Avatar
Christophe Garault
Yannick Loiseau a écrit :

En gros, en 'cgi', t'as un interpréteur Php "standalone", qui peux
executer tes scripts depuis la ligne de commance.



Bonjour,

je complèterai cette excellente explication en indiquant qu'il existe
également un USE flag pour disposer du langage PHP sans en faire un cgi.
Sauf erreur de ma part il s'agit de 'cli'.
En récapitulant pour Philippe, si tout ce qui t'intéresse c'est de faire
fonctionner Horde ou d'autres appli web en php avec Apache alors il
suffit de renseigner ton package.use avec les bons USE flags avant
d'emerger Php. Voici un exemple de ce que j'ai:

marge ~ # cat /etc/portage/package.use|grep -i php
Þv-lang/php-4* -* apache2 berkdb bzip2 calendar cli crypt ctype curl
dba doc exif flatfile ftp gd gdbm iconv imap inifile iodbc jpeg ldap
memlimit mhash ming mysql ncurses nls odbc pcntl pcre pear posix
postgres readline sharedext sharedmem session sockets sqlite ssl tiff
tokenizer xmlrpc truetype xml xsl zlib

Celà signifie que pour tous les ebuild de la branche php4
(Þv-lang/php-4*), je les construis en module (apache2) avec une ligne
de commande (cli) et le framework Pear (pear). Le reste c'est juste là
au cas où... Comme l'a très bien écrit Yannick, le fonctionnement des
scripts est beaucoup plus rapide en module (ici mod_php) qu'en CGI où
Apache doit appeler l'interpréteur avant chaque exécution du script. Les
mongueurs parlent de mod_perl comme d'un Perl sous anabolisants... ;-)

Voilà, concernant le php-toolkit je n'ai pas trop regardé, mais il me
semble que c'est un outil qui permet de choisir son interpréteur Php
entre les différentes versions.

Bonne semaine.

--
Et sous les vieux haubans rongés de lente usure,
Poulies aux yeux crevés sur l'infini perdu,
Témoins momifiés des hommes disparus,
Quel dieu féroce a pétrifié dans vos membrures
Les fantômes railleurs de vos orgueils vaincus.
- Anita Conti.
--
mailing list
Avatar
onvice1
Bonjour à tous,

Alors là bravo messieurs; merci pour vos précieuses explications.
Je n'ai pas encore tout pigé mais par rapport à ce que j'ai fait, je comprends
mieux mais bêtises........ c'est clair j'ai essayé de me débrouiller seul mais
en fait je m'apperçois que ce n'est pas bon car comme vous le dites, je n'ai
pas besoin d'utiliser le php cgi vu que je ne développe pas du tout
d'application.
J'ai vraiment été "barbare" car j'ai bien mis dans mon package.use ces use flag
:
Þv-lang/php-4* cli cgi apache2 ctype expat fastbuild force-cgi-redirect ftp gd
iconv ipv6 memlimit mysql nls pcre pic posix session socket ssl tokenizer
truetype xml xsl zlib -berkdb dba
Þv-lang/php-5* cli cgi apache2 ctype fastbuild force-cgi-redirect ftp gd iconv
ipv6 memlimit mysql nls pcre pic posix pdo-external session simplexml soap
sockets spl sqlite ssl tokenizer truetype xml xsl zlib -berkdb dba

Donc j'aurais encore besoin de vos conseils, que me conseillez-vous?
Mais d'apres mes useflags, n'y a t il pas eu comme meme une partie compilé en
module ??
Est ce que pour l'instant nous avons toujours besoin du php 4 (vu les logiciels
que j'uitlise)?? Ou je peux passer tout en php5 ?
Est-ce que je dois reprendre alternative 2 pour n'avoir que le php4 en cgi et le
php 5 en module dans le cas ou on a toujours besoin des deux .

je suis un petit perdu dans mon utilisation de Php/apache depuis cette mis a
jour.
Merci d'avance pour vos lumières

cordialement

philippe



Selon Christophe Garault :

Yannick Loiseau a écrit :

>En gros, en 'cgi', t'as un interpréteur Php "standalone", qui peux
>executer tes scripts depuis la ligne de commance.
>
Bonjour,

je complèterai cette excellente explication en indiquant qu'il existe
également un USE flag pour disposer du langage PHP sans en faire un cgi.
Sauf erreur de ma part il s'agit de 'cli'.
En récapitulant pour Philippe, si tout ce qui t'intéresse c'est de faire
fonctionner Horde ou d'autres appli web en php avec Apache alors il
suffit de renseigner ton package.use avec les bons USE flags avant
d'emerger Php. Voici un exemple de ce que j'ai:

marge ~ # cat /etc/portage/package.use|grep -i php
Þv-lang/php-4* -* apache2 berkdb bzip2 calendar cli crypt ctype curl
dba doc exif flatfile ftp gd gdbm iconv imap inifile iodbc jpeg ldap
memlimit mhash ming mysql ncurses nls odbc pcntl pcre pear posix
postgres readline sharedext sharedmem session sockets sqlite ssl tiff
tokenizer xmlrpc truetype xml xsl zlib

Celà signifie que pour tous les ebuild de la branche php4
(Þv-lang/php-4*), je les construis en module (apache2) avec une ligne
de commande (cli) et le framework Pear (pear). Le reste c'est juste là
au cas où... Comme l'a très bien écrit Yannick, le fonctionnement des
scripts est beaucoup plus rapide en module (ici mod_php) qu'en CGI où
Apache doit appeler l'interpréteur avant chaque exécution du script. Les
mongueurs parlent de mod_perl comme d'un Perl sous anabolisants... ;-)

Voilà, concernant le php-toolkit je n'ai pas trop regardé, mais il me
semble que c'est un outil qui permet de choisir son interpréteur Php
entre les différentes versions.

Bonne semaine.

--
Et sous les vieux haubans rongés de lente usure,
Poulies aux yeux crevés sur l'infini perdu,
Témoins momifiés des hommes disparus,
Quel dieu féroce a pétrifié dans vos membrures
Les fantômes railleurs de vos orgueils vaincus.
- Anita Conti.
--
mailing list






--
mailing list