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

[flagos <flagospub@xxxxxxxxx>]

La vache, la mise en forme du mail a completement valdingué !

Je vous donne le brouillon que j'avais fait par texte

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

Attachment: besoins_integration
Description: Binary data