ET OUI, J'AI LU TOUTES LES DOCS (aussi immondes voire pire que pour le rpm)
Ensuite, navré, mais j'ai effectivement pas lu toutes les docs, mais je me suis tout de même inspiré de tutoriaux made in debian pour générer un .deb pour la version suivante et ajouter des patchs.
Tu commences déjà par te contredire en moins trois phrases. Ensuite, on t'a parlé de documentation, pas d'un tutorial glané ci ou là sur Internet.
Ensuite a tous les couillons qui m'ont moinsé bêtement, OUI BÊTEMENT !
Tu noteras que les « couillons » auraient certainement moinsé n'importe quel commentaire à propos de RPM avec des propos comme les tiens.
Je vous prie d'aller apt-get source php et ensuite essayer d'ajouter votre patch.
Je n'ai pas de patchs à ajouter à php mais il existe plusieurs outils de gestions des patchs avec les outils debian, comme il existe au moins trois outils de construction (sachant que c'est toujours basé sur dpkg-buildpackage et que le debian/rules reste un Makefile) : dbs, debhelper et cdbs. Pour les outils de patch, on trouve dpatch. Il se trouve que le paquet source de php4 n'utilise aucun outil externe mais a défini des cibles « patch » et « unpatch » dans le debian/rules. C'est un choix du développeur, ça se discute. Cependant, une fois le paquet source téléchargé, les sources ne sont pas patchées (à part pour ajouter le répertoire debian lui-même). Si tu souhaites n'appliquer que les patchs, il suffit de faire make -f debian/rules patch. Note que cette cible est commune à tous les outils. Ensuite, tu peux tenter d'appliquer ton patch (je préfère largement dpatch car il permet de faire des modifications sur les sources puis de générer le patch adéquat avec la commande dpatch-edit-patch).
Je vous souhaite bien du plaisir si ça foire, car les patch set sont tellement merdique qu'ils ne sont pas réversibles !
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).
J'ai eu a patcher apt (a cause d'un bug dans start-stop-daemon), là encore pas très jojo, 3mois mon bug est resté sans réponse alors que je fournissait un PATCH !
(mais bon apt est un paquet tellement inutile on va me dire...)
Je ne vois pas le rapport entre apt et start-stop-daemon dans la mesure où ce paquet ne dispose d'aucun service à démarrer... Et les quelques recherches sur b.d.o et Google ne donne rien de concluant. Encore un lapsus (start-stop-daemon fait partie du paquet dpkg) ? La prochaine fois, précise donc le numéro du bug.
Dernier essai, backporter sous sarge teamspeak-server.
Là encore teamspeak-server utilise des macros (j'ai du récupérer une version suivante).
Impossible de simplement backporter le script, j'ai du me taper toute la ré-écriture du rules, de control et autre...
Tu parles d'un paquet non-free qui n'est disponible que pour testing et toi, tu veux le rétro-porter pour oldstable (sarge). Or, il dépend de lsb-base : tu ne vas tout de même pas reprocher à un paquet prévu pour des versions ultérieures de tirer parti des nouveaux standards... En outre, lsb-base existe déjà pour oldstable (sarge) mais en version 2.0. D'après les dépendances déclarées de teamspeak-server, il dépend de la 3.1 mais il est toutefois possible, puisque ce paquet est apparu APRÈS sarge qu'il soit possible de dépendre de la 2.0 aussi. En outre, concernant debhelper, il dépend de la version 5. Bref, je ne vois pas en quoi il s'agit d'un problème par rapport au format du paquet. 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.
Je le redis, le deb ça pue, c'est TROP compliqué, pas intuitif et vieux !
Et RPM, c'est jeune, intuitif et ça sent bon la rose. Contrairement à RPM, les outils de debian évoluent avec le temps : tu ne peux pas reprocher à ces mêmes outils d'évoluer et en même temps déclamer que c'est « vieux ». Le format RPM est pratiquement aussi vieux (ils ont tous les deux nés vers 1995) et n'a guère évolué depuis.
D'autre part, ne me sortez pas le couplet de ne connais pas, j'ai du m'occuper de ré-intégrer des patchs dans une 50aine de paquet, ça me semble suffisant pour dire que je connais et juger que c'est pourri !
Ce n'est pas une question de quantité mais de qualité des tes arguments. Tu peux avoir eu à ajouter des patchs dans 50 paquets pour des raisons politiques (on ne veut pas encore passer à etch mais c'est dans le prochain cycle) mais tu l'as manifestement dû le faire sans trop lire la documentation ni avec la plus grande motivation du monde vu ton penchant pour RPM.
[^] # Re: Une bonne nouvelle pour Linux...
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Dell choisit Ubuntu pour ses PC. Évalué à 2.
Tu commences déjà par te contredire en moins trois phrases. Ensuite, on t'a parlé de documentation, pas d'un tutorial glané ci ou là sur Internet.
Tu noteras que les « couillons » auraient certainement moinsé n'importe quel commentaire à propos de RPM avec des propos comme les tiens.
Je n'ai pas de patchs à ajouter à php mais il existe plusieurs outils de gestions des patchs avec les outils debian, comme il existe au moins trois outils de construction (sachant que c'est toujours basé sur dpkg-buildpackage et que le debian/rules reste un Makefile) : dbs, debhelper et cdbs. Pour les outils de patch, on trouve dpatch. Il se trouve que le paquet source de php4 n'utilise aucun outil externe mais a défini des cibles « patch » et « unpatch » dans le debian/rules. C'est un choix du développeur, ça se discute. Cependant, une fois le paquet source téléchargé, les sources ne sont pas patchées (à part pour ajouter le répertoire debian lui-même). Si tu souhaites n'appliquer que les patchs, il suffit de faire make -f debian/rules patch. Note que cette cible est commune à tous les outils. Ensuite, tu peux tenter d'appliquer ton patch (je préfère largement dpatch car il permet de faire des modifications sur les sources puis de générer le patch adéquat avec la commande dpatch-edit-patch).
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).
Je ne vois pas le rapport entre apt et start-stop-daemon dans la mesure où ce paquet ne dispose d'aucun service à démarrer... Et les quelques recherches sur b.d.o et Google ne donne rien de concluant. Encore un lapsus (start-stop-daemon fait partie du paquet dpkg) ? La prochaine fois, précise donc le numéro du bug.
Tu parles d'un paquet non-free qui n'est disponible que pour testing et toi, tu veux le rétro-porter pour oldstable (sarge). Or, il dépend de lsb-base : tu ne vas tout de même pas reprocher à un paquet prévu pour des versions ultérieures de tirer parti des nouveaux standards... En outre, lsb-base existe déjà pour oldstable (sarge) mais en version 2.0. D'après les dépendances déclarées de teamspeak-server, il dépend de la 3.1 mais il est toutefois possible, puisque ce paquet est apparu APRÈS sarge qu'il soit possible de dépendre de la 2.0 aussi. En outre, concernant debhelper, il dépend de la version 5. Bref, je ne vois pas en quoi il s'agit d'un problème par rapport au format du paquet. 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.
Et RPM, c'est jeune, intuitif et ça sent bon la rose. Contrairement à RPM, les outils de debian évoluent avec le temps : tu ne peux pas reprocher à ces mêmes outils d'évoluer et en même temps déclamer que c'est « vieux ». Le format RPM est pratiquement aussi vieux (ils ont tous les deux nés vers 1995) et n'a guère évolué depuis.
Ce n'est pas une question de quantité mais de qualité des tes arguments. Tu peux avoir eu à ajouter des patchs dans 50 paquets pour des raisons politiques (on ne veut pas encore passer à etch mais c'est dans le prochain cycle) mais tu l'as manifestement dû le faire sans trop lire la documentation ni avec la plus grande motivation du monde vu ton penchant pour RPM.