[openplacos-dev] Portage sur les différentes distros

[flagos <flagospub@xxxxxxxxx>]

Yop,

J'ai matté un peu les docs d'autoconf, setup.rb et rubygems. Je vous
avoue ne pas avoir tout saisi partout, surtout pour autoconf ;-).
Néanmoins, j'ai voulu reprendre le script d'install (le ubuntu.sh qui
traine) et voir un peu les défis que l'on devait résoudre. J'ai
distingué n certain nombre de cas:

1. bin_dir: contient les executables openplacos, openplacos-server.
Bref, tout ce qu'on peut vouloir appeler depuis $PATH. 	# Geré en tant
que bindir par les systemes de setup: au moins autoconf et setup.rb.
Rubygem a un autre mécanisme tout aussi facile	# Spécifique a chaque
distro	# Typiquement /usr/bin
2. path d'install des sources: Souvent considéré comme un path vers
une librairie dans le monde ruby, setup.rb et rubygem le gerent de la
sorte. Pour autoconf, il s'agit de copie pure et simple	# Geré par les
scripts d'install	# Typiquement  /usr/lib/ruby/
3. integration d-bus: gere la policy de dbus	# Path spécifique a la
distro	# Non géré par les scripts	# Typiquement
/usr/share/dbus-1/system-services/ et  /etc/dbus-1/system.d/
4. boot file: Script de startup/shutdown	# Intimement lié a la distro.
Un script générique peut-etre proposé. C'est au mainteneur de paquet
de choisir s'il le recode pour sa distro ou non	# Path spécifique a
chaque distro
5. operation admin: Il s'agit des petites commandes magiques "adduser
openplacos", "/etc/init.d/dbus reload"  "/etc/init.d/openplacos start"
	# Commandes non génériques	# Les implémentations dépendent des
politiques des distros. Ex: "update-rc.d openplacos defaults 98 02"
qui sert a ajouter le service openplacos au boot de la machine sera
dans un paquet Debian ne sera pas mis dans un paquet Arch. 	# La seule
bonne attitude est de confier cette tache au mainteneur.
6. gestion des dépendances de paquets: Je ne considère ici que les
paquets système, pas les gem	# Non générique, non capitalisable
7. gestion des dépendances pour les gem	# completement portable.
Bundler ou rubygems offre 2 possiblités de les gérer.
Pour moi, seul les points 1, 2, et 7 sont capitalisables entre
distribs. Les autres points me semblent impossible a capitaliser et
rélèvent du pur packaging. Le projet pourra très bien fournir de la
doc ou du template censé marcher, mais je ne vois pas ce qu'on peut
faire de mieux.

Vous voyez d'autres choses a gérer histoire d'améliorer la situation ?

-- 
Tapé depuis mon clavier