rappel: apt et dselect sont des front-end de dpkg.
dpkg : mars 1995
dselect: novembre 1995
apt : mars 1999
urpmi : fevrier 2000
lors de la release de urpmi ( et peut être toujours maintenant ):
- résolution des dépendances oui, mais... par itérations avec un nombre configurable mais fixé !
- _obligation_ d'avoir des interactions homme-machine ( pas d'automatisation )
- pas d'autentification des mirroirs.
- pas d'interface en curse
A lire en l'occurence le lien de freshmeat, la section "Some Implementation Details" où l'on apprend que dans urpmi ( du moins à l'époque):
- pas de trace d'install/config des packages ( installed, half-installed, not-installed, unpacked, half-configured... ). Bref, pour urpmi c'est installé ou pas.
- pas de priorité sur les packages ( required, important, standard, optional... )
Questions persos: Qu'advient-il des fichiers de configuration avec urpmi, sont-ils gardés ou effacés systématiquement puisque pas d'état de transition pour les packages ? J'imagine qu'il n'y a pas de notion de Pre-Invoke, Post-Invoke, Pre-Install-Pkgs ou encore Build-Options, si ?
Vu le _très lourd_ passé des rpms, il ne faut pas s'etonner que des gens qui sont passés sous suse ou debian y restent. Par exemple à l'époque des RH 5.x la gestion des packages se faisait (mieux) avec Debian ou Suse. Une gestion de package, c'est fait pour gagner du temps à defaut de prendre du plaisir ( pour répondre aussi aux slackware et LFS addicts :)
Enfin de façon plus générale, Debian ne se soucie que de la qualité de sa distrib et n'a pas à se préoccuper de rentabilité. Et ça, pour moi, c'est l'argument massue pour l'initiateur de ce thread.
[^] # tant pis si ca score moins...
Posté par Gloo . En réponse à la dépêche Sondages, sondages, sondages. Évalué à 10.
rappel: apt et dselect sont des front-end de dpkg.
dpkg : mars 1995
dselect: novembre 1995
apt : mars 1999
urpmi : fevrier 2000
lors de la release de urpmi ( et peut être toujours maintenant ):
- résolution des dépendances oui, mais... par itérations avec un nombre configurable mais fixé !
- _obligation_ d'avoir des interactions homme-machine ( pas d'automatisation )
- pas d'autentification des mirroirs.
- pas d'interface en curse
Mes sources ( entreq autres ):
- http://www.debian.org/doc/manuals/project-history/ch3.html(...)
- http://freshmeat.net/articles/view/192/(...)
- mon experience ( mais on va dire que c'est subjectif... )
A lire en l'occurence le lien de freshmeat, la section "Some Implementation Details" où l'on apprend que dans urpmi ( du moins à l'époque):
- pas de trace d'install/config des packages ( installed, half-installed, not-installed, unpacked, half-configured... ). Bref, pour urpmi c'est installé ou pas.
- pas de priorité sur les packages ( required, important, standard, optional... )
Questions persos: Qu'advient-il des fichiers de configuration avec urpmi, sont-ils gardés ou effacés systématiquement puisque pas d'état de transition pour les packages ? J'imagine qu'il n'y a pas de notion de Pre-Invoke, Post-Invoke, Pre-Install-Pkgs ou encore Build-Options, si ?
Vu le _très lourd_ passé des rpms, il ne faut pas s'etonner que des gens qui sont passés sous suse ou debian y restent. Par exemple à l'époque des RH 5.x la gestion des packages se faisait (mieux) avec Debian ou Suse. Une gestion de package, c'est fait pour gagner du temps à defaut de prendre du plaisir ( pour répondre aussi aux slackware et LFS addicts :)
Enfin de façon plus générale, Debian ne se soucie que de la qualité de sa distrib et n'a pas à se préoccuper de rentabilité. Et ça, pour moi, c'est l'argument massue pour l'initiateur de ce thread.