[spip-dev] Re: Packaging Debian

fil · Février 12, 2002, 3:40

je suis intéressé pour effectuer le packaging Debian de spip et donc je
me tourne vers vous pour avoir quelques renseignements administratifs

Essaie d'utiliser la liste spip-dev@rezo.net de préférence.

J'ai besoin de connaitre le ou les auteurs avec leur adresse email
respective, car, je tiens à le signaler il n'y a pas de nom (mis à par
la mailing list de développement).

Tu voudrais plus d'informations que n'en donne le site de développement ?
Impossible !

De plus, dans votre packaging, il serait bien de mettre un MANIFEST ou
un entête à chacun de vos fichiers afin de spécifier la licence, la
provenance, ...

Il y a un fichier gpl.txt, qui nous paraît à la fois nécessaire *et*
suffisant. Les tartines à la GNU, bof.

Sinon concernant le packaging propre, je souhaite que spip soit
directement utilisable après installation donc passer l'étape de
configuration qui peut être générée par debconf. Si vous voyez d'autres
méthodes ou bien un autre point de vue sur le packaging voire même un
refus de packaging faites le moi savoir.

Je ne vois pas à quoi peut ressembler un package debian pour spip (ne te
méprends pas : j'utilise debian sur mes serveurs...) Simplement spip est un
truc qu'on installe dans un répertoire donné d'un site web : on peut
l'installer à plusieurs endroits si on a plusieurs sites sous spip... c'est
même assez courant. Les choses qu'on va installer avec debian sont plutôt
des choses centralisées, mutualisées...

A moins que tu penses, en revanche, à un script que tu lances à un endroit
donné de ton arborescence, et qui y installe spip ?

du genre :

cd public_html/
spipinstall

Installation de spip dans le répertoire public_html/
Decompactage des fichiers... spip/... ecrire/...
Changements des permissions sur les répertoires ecrire/ CACHE/ ecrire/data/ (etc)
Création de la base mysql...
Ecriture du fichier ecrire/inc_connect.php3...
OK, votre spip est installé dans http://xxxxxx/

Mais je ne vois pas trop l'utilité, sauf éventuellement pour des hébergeurs
qui voudraient installer et maintenir quelques dizaines de spip sur leur
machine.

-- Fil

Igor_Genibel · Février 12, 2002, 4:39

> J'ai besoin de connaitre le ou les auteurs avec leur adresse email
> respective, car, je tiens à le signaler il n'y a pas de nom (mis à par
> la mailing list de développement).

Tu voudrais plus d'informations que n'en donne le site de développement ?
Impossible !

Et bien si ça a l'air d'être possible (cf mail d'Antoine).

> De plus, dans votre packaging, il serait bien de mettre un MANIFEST
> ou un entête à chacun de vos fichiers afin de spécifier la licence,
> la provenance, ...

Il y a un fichier gpl.txt, qui nous paraît à la fois nécessaire *et*
suffisant. Les tartines à la GNU, bof.

Je n'ai pas mantionné de «tartine» mais seulement un préambule à chacun
des fichier que vous codez peut-être nécessaire pour garantir vos
droits. De plus dans le tarball il n'y a même pas un README indiquant
que le projet est sous GPL. Cette référence est seulement mentionnée
après avoir configuré spip.
Ce ne sont que des remarques, ne voit pas le mal où il n'est pas.

> Sinon concernant le packaging propre, je souhaite que spip soit
> directement utilisable après installation donc passer l'étape de
> configuration qui peut être générée par debconf. Si vous voyez
> d'autres méthodes ou bien un autre point de vue sur le packaging
> voire même un refus de packaging faites le moi savoir.

Je ne vois pas à quoi peut ressembler un package debian pour spip (ne
te méprends pas : j'utilise debian sur mes serveurs...) Simplement
spip est un truc qu'on installe dans un répertoire donné d'un site web
: on peut l'installer à plusieurs endroits si on a plusieurs sites
sous spip... c'est même assez courant. Les choses qu'on va installer
avec debian sont plutôt des choses centralisées, mutualisées...

A moins que tu penses, en revanche, à un script que tu lances à un
endroit donné de ton arborescence, et qui y installe spip ?

Non je ne pense pas à ça.
Le packaging est là pour un but «system wide». Le fait que l'outil,
après décompression, offre un système d'installation n'est pas du tout
remis en cause, bien au contraire ! Pour donner un exemple, je ne pense
pas que spip soit installé dans le répertoire personnel d'un utilisateur
pour le site du monde diplomatique par exemple. Donc le but du packaging
et d'offrir la possiblité d'intégrer directement un soft dans la
distrib. Ce qui peut-être un avantage considérable pour des admins
systèmes. Mais là je dérive

[...]

Mais je ne vois pas trop l'utilité, sauf éventuellement pour des
hébergeurs qui voudraient installer et maintenir quelques dizaines de
spip sur leur machine.

Non plus. En fait pour te donner une autre vision, je prendrai l'exemple
d'un soft quelconque mais disponible en tarball.
Tu fais ./configure --prefix=~home/usr
make
make install
et le soft est disponible pour l'utilisateur. L'offrir en package dans
la distrib permet à tout le monde de l'utiliser. Et l'admin possède une
mise à jour régulière, et garde la cohérence des informations qui sont
stockées sur le disque.

Voilà.

fil · Février 12, 2002, 5:41

@ Igor Genibel <igor@genibel.org> :

Et bien si ça a l'air d'être possible (cf mail d'Antoine).

Antoine, salaud !

Je n'ai pas mantionné de «tartine» mais seulement un préambule à chacun
des fichier que vous codez peut-être nécessaire pour garantir vos
droits.

Un fichier sans mention n'est pas protégé par le droit d'auteur ? Première
nouvelle... En revanche, tu as raison, une mention supplémentaire permet
toujours de couper l'herbe sous le pied à un éventuel argument de "bonne
foi" d'un contrefacteur et, d'autre part, d'être facilement joignable en cas
de problème. Pour le coup il vaudrait mieux que l'email contact soit
spip-dev@rezo.net.

Ce ne sont que des remarques, ne voit pas le mal où il n'est pas.

Ne t'inquiète pas, j'ai eu une journée chargée... et je me refuse en général
à utiliser des smileys.

Et l'admin possède une mise à jour régulière, et garde la cohérence des
informations qui sont stockées sur le disque.

Je dois être mal-comprenant : les fichiers "source" de spip seraient,
disons, dans /usr/lib/spip/, et seraient utilisables directement par
n'importe quel utilisateur ? Où se logent alors les infos de connexion
(inc_connect.php3 ?)

Enfin, vas-y, je pense que je comprendrai mieux quand je le verrai...

-- Fil

Igor_Genibel · Février 12, 2002, 5:53

Antoine, salaud !

> Je n'ai pas mantionné de «tartine» mais seulement un préambule à
> chacun des fichier que vous codez peut-être nécessaire pour garantir
> vos droits.

Un fichier sans mention n'est pas protégé par le droit d'auteur ?

Si bien sûr, mais n'importe quel détracteur pourrait sans vergogne
aucune s'approprier la totalité de spip sauf un seul fichier
ecrire/inc.php3 qui fait mention de la licence de l'outil à la ligne 665
de la version 1.3 de spip. Ce qui pourrait être gênant car il aurait la
possibilité d'«enfermer» les sources.

Première nouvelle... En revanche, tu as raison, une mention
supplémentaire permet toujours de couper l'herbe sous le pied à un
éventuel argument de "bonne foi" d'un contrefacteur et, d'autre part,
d'être facilement joignable en cas de problème. Pour le coup il
vaudrait mieux que l'email contact soit spip-dev@rezo.net.

Ok.

> Ce ne sont que des remarques, ne voit pas le mal où il n'est pas.

Ne t'inquiète pas, j'ai eu une journée chargée... et je me refuse en
général à utiliser des smileys.

Ok, c'est bon à savoir.

> Et l'admin possède une mise à jour régulière, et garde la cohérence
> des informations qui sont stockées sur le disque.

Je dois être mal-comprenant : les fichiers "source" de spip seraient,
disons, dans /usr/lib/spip/, et seraient utilisables directement par
n'importe quel utilisateur ? Où se logent alors les infos de connexion
(inc_connect.php3 ?)

Non, le but est de faire un «system wide» spip dans le sens où, par
exemple une entreprise a besoin d'avoir un système de publication, elle
aura (enfin son admin) besoin de consacrer une partie de son système et
non pas une partie de son espace utilisateur (qui est heureusement situé
ailleurs que sur internet). Donc le but c'est de mettre en place un spip
pour un besoin général. Rien n'empêchera ensuite l'utilisateur lambda de
l'installer pour ses propres besoins.

Enfin, vas-y, je pense que je comprendrai mieux quand je le verrai...

Ok.

fil · Février 12, 2002, 5:59

@ Igor Genibel <igor@genibel.org> :

Si bien sûr, mais n'importe quel détracteur pourrait sans vergogne
aucune s'approprier la totalité de spip sauf un seul fichier
ecrire/inc.php3 qui fait mention de la licence de l'outil à la ligne 665
de la version 1.3 de spip. Ce qui pourrait être gênant car il aurait la
possibilité d'«enfermer» les sources.

Légalement, non. En tous cas sous le régime du droit d'auteur en France.
Evidemment, si le type en question est aux Philippines... on est foutus.

Non, le but est de faire un «system wide» spip dans le sens où, par
exemple une entreprise a besoin d'avoir un système de publication, elle
aura (enfin son admin) besoin de consacrer une partie de son système et
non pas une partie de son espace utilisateur (qui est heureusement situé
ailleurs que sur internet).

je ne comprends toujours pas : spip peut s'installer dans n'importe quel
répertoire web...

> Enfin, vas-y, je pense que je comprendrai mieux quand je le verrai...

bis repetita

-- Fil

Thomas_NOEL · Février 12, 2002, 7:43

Howdy,

Juste pour prendre un peu partie dans un débat :

@ Igor Genibel <igor@genibel.org> :
> Non, le but est de faire un «system wide» spip (...)
je ne comprends toujours pas : spip peut s'installer dans n'importe quel
répertoire web...

Sur Debian, les différents systèmes "à la php" (comme phpmyadmin,
phppgadmin, imp et autres trucs) s'installent à travers des packages qui
se mettent dans /usr/share/xxx/ et qui sont trouvables sur le site à
travers des alias comme /phpmysqladmin ou /imp. Cette configuration est
donc très facilement modifiable via httpd.conf : il suffit par exemple
de changer l'alias pour faire d'IMP (webmail) la racine du serveur web.

L'idée d'Igor, je pense, afin de promouvoir la diffusion de SPIP, est de
proposer un package qui installe SPIP comme cela, à travers un alias
/spip. Ca permet de simplifier l'installation du package et de diffuser
le produit (sur Debian les gens adorent installer plein de truc pour les
tester parce qu'il savent que ça plante très rarement et qu'on peut tout
virer ensuite).

Rien n'empêche dans la doc du package (que tout bon Debianneur lit avant
d'installer un package) d'expliquer qu'il est possible d'installer ce
package n'importe où, avec l'URL du site, etc.

L'interêt est aussi, si Igor décide de vraiment maintenir la chose, de
pouvoir mettre à jour SPIP de façon extrémement simple et automatique.
Donc en quelques coups de baguette magique, hop ! tu as un site SPIP qui
tourne et qui se met à jour avec le reste du système (apt-get upgrade).

Ensuite comme Igor est surement un grand bosseur (pas comme moi) doublé
d'un amoureux de SPIP (comme moi), il fera des packages de squelettes
spip-mondediplo, spip-uzine, spip-rezo, ... hein ? Allez Igor !!!

Moi je vote pour, quoi...

a+

Raphael1 · Février 12, 2002, 8:05

On 12 Feb 2002 19:43:31 +0000

Ensuite comme Igor est surement un grand bosseur (pas comme moi) doublé
d'un amoureux de SPIP (comme moi), il fera des packages de squelettes
spip-mondediplo, spip-uzine, spip-rezo, ... hein ? Allez Igor !!!

On jurerait que tu le connais personnellement, Igor :o)

Moi ce que je ne comprends pas, c'est qu'Igor n'ai pas encore fini
de packager spip pour notre debian preferée.

Raphael

PS : Pour le debat Package/PasPackage, j'apporte ma petite
pierre. L'interêt d'un paquet Debian pour spip est multiple :

1) Plus large diffusion de l'outil
     Non négligeable, comme argument. En plus, il s'installe,
     se met à jours tout seul, et le mainteneur du paquet se
     prends tout les bugs reports à votre place (enfin, il les
     filtres en tout cas). J'ai découvert de nombreux logiciels
     forts utiles, en les voyant apparaitre dans mon dselect.

2) Gestion des dépendances
     Le neuneu de base, en voulant installer spip, se retrouvera
     avec un php, un apache, et un mysql installé, le veinard.
     Et surement déjà configuré surement (vive debconf, meme si
     spip est au moins aussi bon de ce coté la).

3) Tout les avantages cité par les autres avant moi

4) Spip est packagé Debian
     C'est un argument de poids ça. C'est pas n'importe quoi un
     package debian. Enfin, des fois si, mais pas avec Igor :o)
     Mais pour un admin, ça veut dire qu'il sait ou son ses
     fichiers, et que son système est cohérent. Son spip et son
     Imp sont la, avec son mysqlmyadmin, et il sait ou sont les
     fichiers dont ils dépendent.

PS2: J'ai dis que j'étais pour ? Allez Igor !!!

Nicolas_Hoizey2 · Février 18, 2002, 4:21

Bonjour,

je viens de passer Gastero Prod en version 1.3, et j'ai un petit
soucis que je n'avais pas avec la 1.2 ...

Dans mon squelette 'sommaire.html', il y a le code JavaScript
suivant :

fil · Février 18, 2002, 4:30

@ Nicolas Hoizey <nhoizey@phpheaven.net> :

Il faudrait donc que toute séquence échappée soit doublement échappée,
ce qui revient à priori simplement à systématiquement échapper tout \
et tout ' ...

Oui, tu as sûrement raison. En attendant que tu nous dises quelles lignes de
code modifier (flemmards, nous ?), tu peux mettre ton machin javascript dans
un fichier annexe et ne mettre dans ton squelette qu'un <? include('secoue.js') ?>

-- Fil

63438612493668b99328 · Février 18, 2002, 4:37

Ben, figure-toi que c'est bizarre, il me semblait avoir vérifié
cette chose (Fil a le même genre de bidouilles, mais avec du code
PHP - il est sérieux, lui). Il faudra regarder à nouveau.

Bon, la ligne suivante contient le noeud du problème :

$texte .= " \$retour .= '".ereg_replace("'", "\'", $objet->texte)."';\n";

Attention, addslashes échappe en plus les ", qui ne sont pas
déséchappées dans les '...'. Il faut donc une fonction custom.
On peut essayer :

$texte .= " \$retour .= '".ereg_replace("[\\\\']", "\\\\1",
$objet->texte)."';\n";
???

fil · Février 18, 2002, 4:50

@ Antoine Pitrou <antoine@rezo.net> :

Bon, la ligne suivante contient le noeud du problème :
$texte .= " \$retour .= '".ereg_replace("'", "\'", $objet->texte)."';\n";

Il faut faire dans un premier temps un ereg_replace("\", "\\", ...)

-- Fil

Nicolas_Hoizey2 · Février 18, 2002, 4:55

Hello,

Ben, figure-toi que c'est bizarre, il me semblait avoir vérifié
cette chose (Fil a le même genre de bidouilles, mais avec du code
PHP - il est sérieux, lui). Il faudra regarder à nouveau.

En quoi ce n'est pas sérieux de mettre du JavaScript ?

Bon, la ligne suivante contient le noeud du problème :
$texte .= " \$retour .= '".ereg_replace("'", "\'", $objet->texte)."';\n";

Oui, j'avais aussi trouvé ...

$texte .= " \$retour .= '".ereg_replace("[\\\\']", "\\\\1",
$objet->texte)."';\n";

Il manque juste des parenthèses pour que ça marche, ce qui donne :

$texte .= " \$retour .= '".ereg_replace("([\\\\'])", "\\\\1", $objet->texte)."';\n";

Chez moi, ça semble marcher, à vérifier partout ...

-Nicolas

63438612493668b99328 · Février 18, 2002, 7:08

Chez moi, ça semble marcher, à vérifier partout ...

Chez moi aussi