[spip-dev] package spip

Bonjour.

Je viens de faire un package spip pour mandrake, qui devrait être dès demain
sur les mirroirs officiels. Voici quelques remarques à ce sujet.

D'abord les perms de l'archive officielles sont quelque peu erratiques: il y a
des fichiers .css exécutables par exemple... Le fait d'utiliser du .zip
plutôt que du tar.gz doit peut-être y être pour quelque chose cependant.

Ensuite, j'ai du procéder à quelques modifications d'installation afin de
respecter à la fois la politique de packaging mandrake, et FHS (File
Hierarchy Standard). Ainsi, j'ai déplacé les répertoires CACHE et ecrire/data
dans respectivement /var/cache/spip et /var/lib/spip, tout en maintenant la
disposition initiale grâce à des liens symboliques. J'ai également employé le
patch ci-joint afin de placer les logs dans /var/log/httpd/spip.log d'une
part, de désactiver la rotation des logs par spip-lui même au profit de
l'utilisation de logrotate d'autre part.

Ces modifications répondent à mes propres besoins, cependant j'imagine que la
possibilité de configurer la localisation de ces répertoires/fichiers d'une
part, d'inhiber ou non la rotation des logs pourrait être utilement intégré à
spip directement.

Enfin, quelque chose qui reste assez pénible pour l'installation, c'est la
nécessité d'avoir le répertoire ecrire accessible en écriture pour le serveur
web, uniquement afin d'y créer un seul et unique fichier lors de la fin de la
configuration. Autant dans le cas du répertoire IMG, ceci est justifié car de
nouveau fichiers y sont crées régulièrement, autant dans le premier cas il
s'agit d'un évenement ponctuel et unique qui oblige pourtant à spécifier des
droits un peu trop permissifs au niveau du package. Une solution simple
serait, comme pour les logs, que le package puisse créer un fichier vide
accessible en écriture au moment de l'installation.

Voilà, tout commentaire est le bienvenu.

spip-1.7-logging.patch.bz2 (439 Bytes)

Dans le paquet debian, les "sources" restent dans /usr, et tu peut
instancier un spip. Dans ce cas, tu fait une copie des "sources" vers
/var/lib et /var/cache.

Le problème se pose à la mise à jour, asvoir s'il faut recopier
l'intégralité des novelles "sources", ou conserver les modifs de
l'utilisateur.

> Ensuite, j'ai du procéder à quelques modifications d'installation afin de
> respecter à la fois la politique de packaging mandrake, et FHS (File
> Hierarchy Standard). Ainsi, j'ai déplacé les répertoires CACHE et
> ecrire/data dans respectivement /var/cache/spip et /var/lib/spip, tout en
> maintenant la disposition initiale grâce à des liens symboliques. J'ai
> également employé le patch ci-joint afin de placer les logs dans
> /var/log/httpd/spip.log d'une part, de désactiver la rotation des logs
> par spip-lui même au profit de l'utilisation de logrotate d'autre part.

Dans le paquet debian, les "sources" restent dans /usr, et tu peut
instancier un spip. Dans ce cas, tu fait une copie des "sources" vers
/var/lib et /var/cache.

Une véritable copie de toutes les sources, ou juste des parties variables ?

Dans ce que je connais du packaging des applications web sous debian, les
sources php sont dans /usr/share, et un alias au niveau d'Apache fait la
redirection.

Et je sais qu'il y aussi un système de création de bases de données lors de
l'installation du package, et je suis rudement intéressé. Si tu pouvais m'en
dire un peu plus à ce sujet, ça m'intéresse :slight_smile:

Le problème se pose à la mise à jour, asvoir s'il faut recopier
l'intégralité des novelles "sources", ou conserver les modifs de
l'utilisateur.

D'habitude, ces modifications sont conservées pour ce qui touche à la
configuration d'un soft, et perdues pour ce qui concerne le code à proprement
parler. Pourquoi spip serait-il différent à cet égard ?

Une véritable copie de toutes les sources, ou juste des parties variables ?

Toutes les sources, à l'exception de la doc et quelques partie
invariables clairement identifiables.

Dans ce que je connais du packaging des applications web sous debian, les
sources php sont dans /usr/share, et un alias au niveau d'Apache fait la
redirection.

C'est presque ça :slight_smile:

Et je sais qu'il y aussi un système de création de bases de données lors de
l'installation du package, et je suis rudement intéressé. Si tu pouvais m'en
dire un peu plus à ce sujet, ça m'intéresse :slight_smile:

J'utilise debconf, ce qui permet effectivmeent de faire le tour de
toutes les instances correctement paramétrées à chaque manipulation du
package. Mais c'est spécifique Debian.

> Le problème se pose à la mise à jour, asvoir s'il faut recopier
> l'intégralité des novelles "sources", ou conserver les modifs de
> l'utilisateur.
D'habitude, ces modifications sont conservées pour ce qui touche à la
configuration d'un soft, et perdues pour ce qui concerne le code à proprement
parler. Pourquoi spip serait-il différent à cet égard ?

Parque (malgré moultes remaqrques là dessus), il n'y a pas de séparation
claire entre le source et les données dans le repertoire écrire. Il y a
certes la quasi totalité du code, mais également els inc_meta* qui ne
peuvent être gérées correctement (avec aucun mélange DirAlias / ln -s
que j'ai réussi à faire).

La solution serait pour moi de sortir les inc_meta de écrire, les mettre
dans data, par exemple, ou ailleurs... Ainsi que db_connect, mais je
n'ai pas encore eu d'echo favorable sur cette liste.
Donc.. pas de séparation, et besoin de cette réplication pénible à
chaque fois.

La solution serait pour moi de sortir les inc_meta de écrire, les mettre
dans data, par exemple, ou ailleurs...

inc_meta_cache EST dans data/ (spip 1.7)

Ainsi que db_connect

celui-là (inc_connect.php3) n'y est pas, d'ailleurs ça ne serait pas un
super idée étant donné que data/ ne contient que des fichiers "effaçables",
c-à- non indispensables. Mais par contre on doit pouvoir spécifier un chemin
alternatif quelque part, il faut voir les implications (installation,
upgrade, etc.)

-- Fil