> dans l'autre tu prends volontairemment l'outil moins adapté?
Remarque pertinante.
Il y a plusieurs raisons.
Si les paquetages que je récupère sont centralisés et cohérents avec mon système RH 8.0 (paquetage RH 8.0 pour RH 8.0 du site RedHat, ou paquetage pour RH8.0 sur freshrpms) je suis plutôt pour l'utilisation d'outils de plus haut niveau. Sinon, çà fini toujours par foirer.
Un exemple. Je veux installer gnucash v 1.6.8 (RH 8.0 est livré avec 1.6.6). Cette version est disponible dans la distribe Rawhide de RedHat. Si je prends le binaire de gnucash de Rawhide, je dois passer à gtkhtml version 1.1.x. Or evolution de RH8.0 ne marche pas avec gtkhtml 1.1.x mais avec gtkhtml 1.0. Notes que les paquetages sont renseigné avec gtkhtml >= 1.0.4 et non avec gtkhtml >= 1.0.4 && < 1.1 . C'est déjà une anomalie que ne détecte pas urpmi . Donc je doit aussi mettre à jour evolution pour avoir gnucash 1.6.8. Hors la version d'evolution qui utilise gtkhtml 1.1 est la version 1.2. Cette version nécessite aussi de mettre à jour bonobo-conf, pilot-link et oaf. Bref je modifie d'un peu partout mon système uniquement pour passer de gnucash 1.6.6 à 1.6.8. De plus evolution 1.2 me semble un peu trop récent pour lui faire comfiance de gérer mon courrier. Il est claire que l'on peut trouver des cas encore plus complexe...
Pour mon cas, j'ai récupéré gnucash-1.6.8-x.src.rpm, retouché le fichier .spec et recompilé. En effet, les sources gnucash supportent gtkhtml 1.0. Et c'est tout ce que j'ai fais...
Seconde raison. J'aime avoir un système avec les paquetages de développement pour compiler des applis si nécessaire. Si j'utilise urpmi je ne suis pas sûr que ce que j'installe peut être compilé. C'est-à-dire que je n'ai pas forcément les paquetages devel de ma configuration (ou que je pourrai les retrouver). En compilant les nouveaux paquetage que j'installe je suis sûr que mon environnement de développement est synchro avec les programmes installés.
Je fait çà depuis longtemps. Et même si c'est un peu fastidieux çà marche très bien. J'avais une RH 6.2 avec Mozilla 1.0, galeon 1.2, evolution 1.0, gnucash 1.6, etc... et toujours une installation propre. Je doute fortement que urpmi, apt4rpm etc m'aurai permis de faire çà. Sinon ce serait avec le même contraite que Debian. C'est-à-dire que tout est centralisé, un gestion de paquetage lourdigue (pour ceux qui font les paquets), etc...
[^] # Re: www.apt-get.org
Posté par matiasf . En réponse à la dépêche www.apt-get.org. Évalué à 0.
Remarque pertinante.
Il y a plusieurs raisons.
Si les paquetages que je récupère sont centralisés et cohérents avec mon système RH 8.0 (paquetage RH 8.0 pour RH 8.0 du site RedHat, ou paquetage pour RH8.0 sur freshrpms) je suis plutôt pour l'utilisation d'outils de plus haut niveau. Sinon, çà fini toujours par foirer.
Un exemple. Je veux installer gnucash v 1.6.8 (RH 8.0 est livré avec 1.6.6). Cette version est disponible dans la distribe Rawhide de RedHat. Si je prends le binaire de gnucash de Rawhide, je dois passer à gtkhtml version 1.1.x. Or evolution de RH8.0 ne marche pas avec gtkhtml 1.1.x mais avec gtkhtml 1.0. Notes que les paquetages sont renseigné avec gtkhtml >= 1.0.4 et non avec gtkhtml >= 1.0.4 && < 1.1 . C'est déjà une anomalie que ne détecte pas urpmi . Donc je doit aussi mettre à jour evolution pour avoir gnucash 1.6.8. Hors la version d'evolution qui utilise gtkhtml 1.1 est la version 1.2. Cette version nécessite aussi de mettre à jour bonobo-conf, pilot-link et oaf. Bref je modifie d'un peu partout mon système uniquement pour passer de gnucash 1.6.6 à 1.6.8. De plus evolution 1.2 me semble un peu trop récent pour lui faire comfiance de gérer mon courrier. Il est claire que l'on peut trouver des cas encore plus complexe...
Pour mon cas, j'ai récupéré gnucash-1.6.8-x.src.rpm, retouché le fichier .spec et recompilé. En effet, les sources gnucash supportent gtkhtml 1.0. Et c'est tout ce que j'ai fais...
Seconde raison. J'aime avoir un système avec les paquetages de développement pour compiler des applis si nécessaire. Si j'utilise urpmi je ne suis pas sûr que ce que j'installe peut être compilé. C'est-à-dire que je n'ai pas forcément les paquetages devel de ma configuration (ou que je pourrai les retrouver). En compilant les nouveaux paquetage que j'installe je suis sûr que mon environnement de développement est synchro avec les programmes installés.
Je fait çà depuis longtemps. Et même si c'est un peu fastidieux çà marche très bien. J'avais une RH 6.2 avec Mozilla 1.0, galeon 1.2, evolution 1.0, gnucash 1.6, etc... et toujours une installation propre. Je doute fortement que urpmi, apt4rpm etc m'aurai permis de faire çà. Sinon ce serait avec le même contraite que Debian. C'est-à-dire que tout est centralisé, un gestion de paquetage lourdigue (pour ceux qui font les paquets), etc...