• [^] # Re: Une bonne nouvelle pour Linux...

    Posté par (site web personnel) . En réponse à la dépêche Dell choisit Ubuntu pour ses PC. Évalué à 2.

    Sauf que ça a pas marché comme ça (crois bien que ça m'aurais arrangé que ça marche "simplement")

    J'ai du rajouter mes patchs au debian/patch.d/ (ou un truc dans ce style).

    Car le paquet php venait avec des patchs.

    Je lui ai mis l'indicatif 52 de mémoire car le dernier était 51

    Hors, lorsque mon patch était appliqué, pour une raison X ou Y, il ne se réversait pas !
    (en fait c'était mon patch le coupable, mais le un autre dans la liste 41 ou 32, c'est trop loin et pas le temps de regarder).

    Bref, c'est pour ça que je dis que c'est du gros n'importe quoi, j'ai déjà vu des patchs foirer, mais alors un outil pour packager qui arrive pas a réverser les patch, ben pour moi ça pue !

    Et j'ai perdu une 50aine de fois a build et faire les paquet un a un, en repartant de l'archive originale a chaque fois...

    Bref, il y a la théorie et la pratique...

    Sans parler que leur paquet te build le cli, sapi et autre en nettoyant à chaque fois.

    ps : mon patch n'était pas trivial, j'ajoutais un module upm (upload progress meter) qui touchais au rfcXXXX.c (la section réception d'upload de php)
    Et je faisait rebuilder une seconde fois l'ensemble des binaires.
    (la première me permettait d'extraire les symboles, de les versioner a coup de perl, puis à la seconde de recompiler en appliquant cette table de conversion)

    Le but avoir php4 et php5 chargé en sapi dans apache en même temps.
    (bon faut les compiler en tout static sans module dynamiques, mais ça marche)

    La raison pour laquelle je dis que le système debian merde est que ça m'est pas arrivé que sur php, j'ai eu le même genre de merde sur proftpd, bind et compagnie.

    Et le pire est que refaire la même chose sous mandriva (après avoir changé de système sur le serveur), m'a pris moins de 5minutes montre en main.
    (a l'époque j'étais une vrai bille pour créer des rpm)

    Bon une réponse rapide a la mauvaise foie de Raphael Surcouf.
    (tu défends debian c'est ton problème, mais retire tes oeillères)

    C'est effectivement dans dpkg que le problème se situais, pardon, je met sur le même plan apt et dpkg au niveau du paquet système critique qui doit pas être buggué !
    Note que lors des recherches sur le b.d.o. tu as du voir comme moi un nombre important de bugs dans ces paquets, franchement c'est un des points qui m'a convaincu de quitter debian.
    Même mandriva qui est pas connu pour sa robustesse, n'a pas(plus ok) de bugs critiques dans son système de package.

    Oui, ce n'est jamais simple de rétro-porter un paquet d'une saveur à une autre surtout quand il y a eu autant de changemetns entre les deux.

    Scuze moi, mais rétroporter pour 10.0-10.1 un paquet de cooker de maintenant c'est possible a moindre frais !
    (trois macros a dégager et le tour est joué)
    Quand au dépendance des paquets debian, franchement y a des fois on se demande comment elle sont faite...
    J'ai vu des dépendances complètement inutiles en dépit du bon sens parfois !

    Que veux-tu par « non réversible » ? La cible « unpatch » permet précisément de les enlever de la source et comme je l'ai déjà dit, ils ne sont pas appliqués lorsque les sources du paquet viennent d'être décompressées. En outre, la cible « clean » intègre la cible « unpatch ». Un tutorial ne remplacera jamais une documentation complète (et pourtant, on pourrait juger celle de RPM sur ce point).

    Désolé, mais je suis tombé sur des rpms merdiques, mal foutu, mais jamais un paquet s'est avéré ne pas être foutu de réverser ses patchs !

    Là j'ai qu'un seul regret, ne pas avoir fait des screenshots histoire de clore le bec de ces intégristes de mauvaise foie !