Le 23/04/2014 23:33, Eric Noulard a écrit :
> Non mais je ne comprends pas.
> Tu as remplacé ton CPackRPM.cmake de ton système avec celui
> que tu as patché puis tu as tenté un cpack -g RPM et le tsp.spec
> généré n'est pas bon?
>
>
Oui c'est effectivement celà. Apparement dans ma version de cmake (2.6),
la substitution des variables de type @CMAKE_VARIABLE@ ne se fait pas.
En regardant le code de CPackRPM, j'ai vu que les variables substituées
étaient au format ${CMAKE_VARIABLE}. En faisant cette adaptation au
patch, j'ai pu avancer.
Il manquait cependant quelque chose : le RPM_BUILD_ROOT n'etait pas
initialisé à la bonne valeur. J'ai donc adapté le CPackRPM.use en
rajoutant --buildroot=${CPACK_TEMPORARY_DIRECTORY} pour forcer
l'initialisation avec le bon chemin.
Une fois celà fait, le RPM s'est généré via CPACK.
> Ok si tu sais faire ça c'est probablement la meilleure méthode.
> CPack sait générer des RPMs et de DEBs mais il sont considérés
> comme "impurs" par des packageurs de distrib'.
Je pense que c'est un tradeoff à faire. Disons que si on a quelqu'un qui
peut faire le packaging avec les outils natifs de la distribution je
pense que c'est le mieux. Chaque projet est pour moi unique est on gère
mieux les spécificités en pouvant modifier finement le SPEC file ou le
debian/rules ou je ne sais quel autre outil.
Après si effectivement le projet n'a pas de ressources dévouées au
packaging, un outil comme CPACK fait très bien le job surtout que
effectivement l'outil s'est beaucoup enrichi et pour TSP il n'y a pas
trop de trucs spécifiques.
> C'est la première question à se poser tu as raison.
>
> Tout ce qui n'est pas utilisé devrait être supprimé et ressuscité plus tard si
> quelqu'un en a besoin. Maintenir des choses utilisées est déjà suffisamment
> chronophage pour ne pas avoir à maintenir des trucs inutilisés...
> Pour finir si les DEB et RPM sont utiles le mieux est de les générer avec
> les moyens/outils familier de celui qui fera le boulot. SI j'avais à le faire
> (mais je ne le ferais pas par manque de temps) j'aurais utilisé CPack
> si c'est toi ou une autre personne qui le fait je pense que c'est à elle
> de choisir.
Pour le moment de ce que je sais, je pense que la version source et la
version RPM sont les plus attendues. Pour la 0.8.4, je pense que je vais
partir du template de spec file utilisé par RpmTools qui me semble plus
aboutit d'autant que si le CPack fourni dans RHEL / CentOS ne fonctionne
pas correctement.
Après ca pourrait être intéressant de remonter le bug a Redhat avec le
patch pour qu'il soit commité et redescende dans CentOS.
Olivier
_______________________________________________
Tsp-devel mailing list
Tsp-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tsp-devel
