Je me permet de venir répondre directement sur "pourquoi avoir fait urpmi plutot que reprendre apt sur mandrake".

La réponse est trés simple :

Le c++, c'est nul à chier. C'est un peu lapidaire comme avis, je sais.

Le c++ est complexe, je pense pas qu'on me contredise sur ce point. Les messages d'erreurs ne sont pas souvent des plus clairs, il y les problémes de liens quand on upgrade 2 bibliothéques c++ sans recompiler et ça devient trés vite long pour faire des trucs qui prennent 3 lignes en perl.
Je ne pense pas que perl soit idéal, mais au moins, il n'y a pas de problémes de mémoire, de copie d'instances cachés et toutes les autres horreurs du c++.

Je suis la personne qui s'occupe du paquet de apt pour mandrake en ce moment et j'ai passé beaucoup trop de soirée sur ce fichu programme, à attendre que ça compile, à comprendre la logique super compliqué des classes en c++.
Le code source de apt fait facilement 4 fois plus de lignes de codes que urpmi, sans pour autant faire 4 fois plus de choses.
Par exemple, au lieu d'utiliser libcurl, apt reprends ses propres routines. Alors, le coup de "pas faire comme debian", on repassera, merci. Le syndrome du "Not Invented Here" frappe assez fort chez nos amis à la spirale.

Mandrake avait le choix entre
* se baser sur apt :
- écrit un language ou les compétences internes sont moins répandus ( c++ ),
- un language bien plus complexe ( donc plus lourd a écrire et a maintenir ),
- un language plus prompt aux erreurs et aux fuites mémoires
- le tout en offrant quasiment rien dans ses bibliothéques ( on peut comparer la stdlib et cpan, si quelqu'un en doute ),
- tout ça pour pouvoir adapter un programme également compliqué
(suffit de voir des 3000 options de apt déstinés a permettre des trucs que personne ne devrait faire comme mélanger les releases et gerer 200 sources concurentes avec un systéme de scores )
- un programme basé avec un format de paquet différent qui est trés fortement ancré dans le code source ( donc qui nécessite de trés fortes adaptations ), pour au final devoir faire un fork ( comme connectiva a du le faire, apt-rpm étant séparé de apt-deb, il y a même des trucs en plus sur celui en rpm )

* refaire un outil de zero pour etre libre, pouvoir faire les choix technologiques qu'ils veulent.

ils ont préferés choisir le deuxiéme, pour ne pas avoir de probléme. Sachant que la plupart des outils ( rpmdrake , mcc ) était déja en perl, que les devs connaissent perl, le choix n'est pas si idiot. Les bibliothéques d'accés à rpm sont reprises dans le centre de controle et rpmdrake, et ils peuvent profiter de la bibliothéque de fonctions perl. Je ne dit pas que urpmi est parfait, loin de la hélas.

Ensuite, à l'usage, c'est une question de gout. Pour installer un programme, il y pas un plus compliqué que l'autre, et entre rpmdrake et synaptic , il y a le choix des interfaces graphiques.


Pour utiliser régulierement apt et urpmi sur mandrake, je sais que apt est aussi lent qu'urpmi à cause du type d'index ( hdlist ) par défaut utilisé sur mandrake , qui sont particuliérement lourd. Les fichier synthésis ( synthesis.hdlist ) améliore les perfs au détriment des infos présentes dans la base, mais c'est un autre débat.

Pour finir, et pour relancer le troll, personne ne parle jamais de yum ?
C'est pourtant un outil écrit dans un language propre ( python ) et disposant de fonctionnalités semblables à urpmi/apt

[www.phy.duke.edu]

Poste le Saturday 27 December 2003 00:36:38

Et emerge?

Poste le Saturday 27 December 2003 03:33:45

>(suffit de voir des 3000 options de apt déstinés a permettre des trucs que personne ne >devrait faire comme mélanger les releases et gerer 200 sources concurentes avec un >systéme de scores )

bah moi je m'en servais tout le tps...comme ca, ca permettait de régler le problème des sources temporairement indisponibles...



j-t muyl (maston28), sale jeune

Poste le Saturday 27 December 2003 10:09:39