> yop
> je me demande si le point 3 n'est pas capitalisable. A priori les fichiers
> de conf dbus ne changent pas d'une distrib a l'autre.
> c'est juste le path qui me semble différent. (c'est pas comme le point 4 ou
> c'est à la fois le fichier et le path qui diffère dans chaque distrib)
>
> Le 10 décembre 2011 16:46, flagos <
flagospub@xxxxxxxxx> a écrit :
>>
>> 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
>>
>>
>
--
Tapé depuis mon clavier