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 marrant mais je pensais la même chose de toi sauf que je ne me permet d'attaques ad hominem.
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 j'ai fait l'effort de rechercher un peu plus loin que le peu d'informations que tu as fournis. Tu ne fais pas beaucoup d'efforts et ton dernier post plus bas prouve soit que tous ces problèmes remontent loin soit que tu n'es pas précis dans ta méthode.
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.
Je ne connais pas la politique de résolutions des bogues chez MandrivaSoft mais concernan le projet Debian, un rapport ne peut être clos que par sa résolution que ça vienne du responsable ou de la part de l'auteur. Il arrive donc facilement que certains rapports restent ouverts pendant des années. Sans vouloir défendre aveuglément Debian (car il existe des DD assez cons, mais comme partout), quand on ne peut pas reproduire l'anomalie constatée par l'auteur pour X raisons, il est souvent difficile de trouver l'origine du problème. Si je voulais faire de la mauvaise foi, je dirais qu'un éditeur commercial n'a aucun intérêt à laisser des rapports de bogues publics ouverts trop longtemps. De là à penser qu'il puisse les clore de façon intempestives (qui n'a pas connu un service de support commercial pourra sans doute me dire le contraire).
Maintenant, je ne sais pas ce que tu valais à l'époque où tu as eu des problèmes mais tu ne devais pas connaître les principes d'un Makefile et c'est bien dommage. J'admets que ça peut rebuter mais ce genre d'outils permet non seulement de connaître les différentes étapes de la construction mais aussi de jouer telle ou telle cible (notamment éviter de tout recompiler après avoir simplement modifier le debian/control pour les dépendances ou autre).
Pour reprendre les propos de Barnabé, je serais curieux de savoir ce que tu veux dire par « reverser les patches » et j'irais même plus loin en te demandant de te remémorer ta procédure ainsi que les éventuels patchs.
[^] # 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é à 1.
C'est marrant mais je pensais la même chose de toi sauf que je ne me permet d'attaques ad hominem.
Note que j'ai fait l'effort de rechercher un peu plus loin que le peu d'informations que tu as fournis. Tu ne fais pas beaucoup d'efforts et ton dernier post plus bas prouve soit que tous ces problèmes remontent loin soit que tu n'es pas précis dans ta méthode.
Je ne connais pas la politique de résolutions des bogues chez MandrivaSoft mais concernan le projet Debian, un rapport ne peut être clos que par sa résolution que ça vienne du responsable ou de la part de l'auteur. Il arrive donc facilement que certains rapports restent ouverts pendant des années. Sans vouloir défendre aveuglément Debian (car il existe des DD assez cons, mais comme partout), quand on ne peut pas reproduire l'anomalie constatée par l'auteur pour X raisons, il est souvent difficile de trouver l'origine du problème. Si je voulais faire de la mauvaise foi, je dirais qu'un éditeur commercial n'a aucun intérêt à laisser des rapports de bogues publics ouverts trop longtemps. De là à penser qu'il puisse les clore de façon intempestives (qui n'a pas connu un service de support commercial pourra sans doute me dire le contraire).
Maintenant, je ne sais pas ce que tu valais à l'époque où tu as eu des problèmes mais tu ne devais pas connaître les principes d'un Makefile et c'est bien dommage. J'admets que ça peut rebuter mais ce genre d'outils permet non seulement de connaître les différentes étapes de la construction mais aussi de jouer telle ou telle cible (notamment éviter de tout recompiler après avoir simplement modifier le debian/control pour les dépendances ou autre).
Pour reprendre les propos de Barnabé, je serais curieux de savoir ce que tu veux dire par « reverser les patches » et j'irais même plus loin en te demandant de te remémorer ta procédure ainsi que les éventuels patchs.