• [^] # Re: Re

    Posté par . En réponse au journal Mise à jour de programmes. Évalué à 2.

    Tu vas te faire te faire taper dessus toi...


    Ouais ben n'empêche que j'ai déjà commencé dans les forums => pas de réponse. Je poste ici et en deux heures des gens s'intéressent à mon cas...

    un rpm de plus de 100 Mo, c'est MAL©[1]


    Quand tu as beaucoup de données sans répartitions fonctionnelles précises, tu es bien obligé de le faire. Par exemple j'ai pour 100Mo d'images dans un paquet.

    Lorsque l'on découpe des paquets avec des -devel -man -data etc.... ce sont des découpages fonctionnels. Or si je découpe mes paquets, ce seront des découpages techniques, ce qui m'embête beaucoup car il n'ont aucune réalité fonctionnelle.

    Ca m'embêterait d'avoir a-1.rpm a-2.rpm a-3.rpm pour la simple raison qu'on ne sait pas quel fichier est dans quel rpm... .De plus pour supprimer le paquet a en entier, il faut supprimer 3 paquets.

    Enfin, quelle granularité appliquer aux RPMs ? De manière générale, je trouve qu'il est dommage de déployer ne serait-ce qu'1Mo lorsque l'on doit modifier un fichier texte de 2Ko !

    La solution à laquelle je pense le plus, c'est de ne pas utiliser RPM ! Je pense faire un repository central basé sur CVS ou SVN qui référence les fichiers de mes applis. Lorsqu'un des fichiers de mes appli change, je sais faire un patch de manière quasi automatique que je déploye ensuite sur tous mes serveurs. Les patchs pourront être packagés en RPM ;-)

    Au lieu d'avoir 1 base RPM sur chaque serveur (soit plus d'une centaine de bases), je n'aurais qu'une base centrale qui assurera la cohérence de mes packages déployés.