"A chaque présentation d'un logiciel dans LinuxMag, on a le droit à la sempiternelle formule "les heureux utilisateurs d'une Debian pourront se contenter d'un apt-get install machin-chose, tandis que les autres devront affronter la lourde et hasardeuse installation manuelle..." (sous-entendu : bien fait pour eux). Et pourtant, c'est largement inexact. D'abord, Connectiva a ajouté le support du format rpm à apt-get, qui doit donc être standard dans cette distribution, et tant Mandrake que RedHat proposent depuis apt-get dans leurs contributions respectives. Ensuite, Mandrake propose toujours son propre outil, urpmi, dont les fonctionnalités ne cessent de grandir, et qui rend possible l'opération précédente avec la même simplicité : urpmi machin-chose, et tour est joué."
Un enseignant de Jussieu présente ici une des plus belles contributions de MandrakeSoft au Libre : l'outil URPMI qui permet de résoudre automatiquement les dépendances à l'installation d'un nouveau package, mais aussi la manière de l'installer très simplement pour une utilisation avec une distribution non-Mandrake qui utilise RPM (comme Red Hat ou SuSE).
Aller plus loin
- La présentation de URPMI (13 clics)
# nécessaire mais pas suffisant
Posté par Xavier Bestel (site web personnel) . Évalué à 6.
[^] # Re: nécessaire mais pas suffisant
Posté par Serge2 . Évalué à 8.
[^] # Re: nécessaire mais pas suffisant
Posté par Dams Nadé (site web personnel) . Évalué à 10.
Figure toi que avant-hier, avec apt-get, je suis passe' d'une redhat 7.1 a une redhat 7.2 sans aucun probleme..
Je sais pas d'ou tu le sors ton graphe de dependance (d'ailleurs si quelqu'un a un joli programme qui fait des jolis dessins pour faire ca, ca m'interesse !:P) mais, theoriquement et pratiquement, _rien_ ne doit etre installe' en --nodeps/--force. D'ailleurs ou boulot je coupe les petits doigts de ceux qui le font. =]
[^] # Graph de de deps.
Posté par GrosBenny . Évalué à 8.
Pense a prendre une feuille A0 pour imprimer :)
D'ailleurs, si tu peux partager ton resultat, ca peut etre interessant.
~> apt-cache --help
apt 0.5.4 for linux [...]
dotty - Generate package graphs for GraphVis
[^] # Re: nécessaire mais pas suffisant
Posté par th0m ask me . Évalué à 7.
Je n'ai jammais utiliser de --nodeps sur des machine en prod, et elles sont toutes a jour. up2date marche tres bien.
[^] # Re: nécessaire mais pas suffisant
Posté par Tony Gencyl . Évalué à 5.
La RH 7.2 je l'utilise depuis 2 mois (apres un long periple de 4 ans sous debian), et je la trouve terri ble !!
Seule remarque a propos des MAJ: mefiez-vous des MAJ proposees par Ximian (par l'intermedaire de ReadCarpet), un collegue de travail en a fait les frais, son "inittab" a ete corrompu :-(((
H.
[^] # Re: nécessaire mais pas suffisant
Posté par #3588 . Évalué à 10.
Je n'ai jammais utiliser de --nodeps sur des machine en prod
En fait il s'agit surtout d'avoir une source de packages cohérents.
Les utilisateurs de Debian en ont une, le site Debian, avec vraiment beaucoup de packages (par exemple 2 fois plus dans Potato que dans la RH du meme moment). De plus, pas mal de packages non officiels sont réalisés par des développeurs Debian (donc pour la distrib), et les outils pour créer les packages visent bien à faire un package spécifiquement pour Debian. D'où une cohérence très élevée dans les packages et leurs dépendances.
Coté RPM, il faut bien distinguer ce que l'on entend par "package RPM". S'agit-il
- du "rpm moyen" (trouvé sur les sites de distribs, rpmfind, etc.)
- du rpm officiel, de la distrib qu'on utilise.
Dans le premier cas, il y a beaucoup de distribs utilisant les RPM et les sites de logiciels fournissent aussi souvent un RPM à coté du tar.gz. De ce point de vue là, il y a une cohérence relativement faible par rapport aux packages deb qu'on peut trouver (cf certains RPM spécifiques SuSE non compatibles RH, etc.)
Dans le deuxième cas, si on ne prend que les RPM officiels de sa distrib, on a a priori une cohérence beaucoup plus grande qui, comme pour Debian, représente bien le travail apporté par les packageurs. Et si on se contente de cette source, tout doit bien se passer.
Les rpm peuvent apparaitre de qualité moyenne si on fait n'importe quoi, mais c'est à cause des sources, et des "destinations" de ces packages, trop différentes. Par contre si on reste sur une unique source (a priori la distrib), la qualité globale et les dépendances sont certainement bonnes.
[^] # Re: nécessaire mais pas suffisant
Posté par PLuG . Évalué à 3.
il y a trop de distrib differentes qui utilisent le systeme RPM ?
ou alors les utilisateurs sont trop con pour n'installer que des RPM destinés a leur distrib ??
[si pas dispo, telecharger le rpm source et faire un rpm -ba package n'est pas difficile quand meme !!]
<Humour>
Ah, si seulement RedHat avait release RPM en closed source, les autres distrib ne s'en seraient pas servies et tout le monde serait heureux car en telechargeant un RPM on serait sur qu'il a été fait pour RedHat.
</Humour>
[^] # Re: nécessaire mais pas suffisant
Posté par Timbert Benoît . Évalué à 9.
Y'aurait peut être eu des tonnes de distributions en DEB, et ça aurait sans doute été le même bordel, qu'avec les distributions en RPM...
Quelqu'un utilise SLP ? (à part Stampede)
[^] # Re: nécessaire mais pas suffisant
Posté par Pierre Tramal (site web personnel) . Évalué à 1.
oui, wmcoincoin est fourni depuis la 2.3.5 avec son SLiP
-1 et je ---->[]
[^] # Re: nécessaire mais pas suffisant
Posté par #3588 . Évalué à 1.
euh, qu'il faut avoir des sources cohérentes et faire attention à ce que l'on prend comme RPM ? A moduler en fonction de la stabilité qu'on attend (machine de prod/machine perso...) bien sur...
il y a trop de distrib differentes qui utilisent le systeme RPM ?
non, pas vraiment, en fait un RPM SuSE incompatible RH devrait etre classé "RPM SuSE", comme si c'était un format différent (c'en est d'ailleurs un puisqu'il y a des choses implicitement attendues sur le système cible). C'est juste un problème de nommage... Et encore, comme d'autres l'ont dit, quand on prend ses RPM RH chez RH, pas de problème du tout...
ou alors les utilisateurs sont trop con pour n'installer que des RPM destinés a leur distrib ??
Non, c'est tentant d'installer un package plutot que de compiler... j'ai une Debian et moi aussi quelques lignes de sources.list référençant des debs non officiels, ne correspondant pas forcément à ma distrib actuelle (on peut trouver des sources dédiées à Potato, d'autres à Sid, et mélanger peut poser problème).
Les utilisateurs font ce qu'ils veulent, mais blamer "les rpm en général" juste parce qu'on a pris un package pas prévu pour sa distrib, c'est excessif. Le besoin de packages LSB, il est bien présent.
Ca veut dire simplement que si on a une machine de production qui doit etre stable, on n'installe pas le premier RPM venu. On installe ceux de la distrib, et pour tout soft non présent dans la distrib, on peut par exemple faire une installation (par compilation) dans /usr/local pour que le système de packages reste propre. Meme s'il existe des RPM pas officiels, mieux vaut les éviter.
Pour une machine perso, soit on fait pareil et ce sera stable du point de vue systeme de packages, soit on prend des RPM un peu n'importe où et faut pas s'étonner que ça déconne...
[^] # Re: nécessaire mais pas suffisant
Posté par nodens . Évalué à -2.
euh... à condition d'avoir une grosse bi^Wbande passante et au moins 8Go à consacrer à son nunux, of course...
[^] # Re: nécessaire mais pas suffisant
Posté par PLuG . Évalué à 10.
Moi je rouspete souvent apres RedHat (mais les autres c'est pareil) qui mettent des dependance telles que tu ne peux pas installer un client X sans avoir le serveur.
par exemple je veux mettre fwbuilder, ou meme juste un xload sur un serveur qui ne possede pas de serveur X11. C'est tres utile, il suffit de se logguer en ssh dessus, ssh exporte le display automatiquement et je peux faire tourner le client X11 et afficher sur le serveur X de mon portable.
la seule méthode "propre" que j'ai trouvé c'est de piquer les libs X11 et le binaire sur une autre machine et de la copier sur le serveur.
Sous redhat (mais les autres c'est pareil), pour installer les libs X11 il faut installer le serveur. Pour installer un client (xclock par exemple), il faut avoir les libs ET le serveur. Enfin pour l'export display il faut xauth (un client X11) qui ne s'installe pas sans serveur ...
Bref ces dependances c'est un vrai plat de nouilles. Sans parler des packages utilent pour Gnome (SDL par exemple) qui dependent aussi de truc KDE. soit c'est --nodeps, soit il faut tout installer.
Donc je résume: vous n'utilisez jamais --nodeps. Tant mieux pour vous, mais je présume que c'est parceque vous ne regardez pas trop ce qui est installé sur votre machine. faites un "rpm -qa" et posez vous la question pour chaque package: "a quoi ca sert, en ai-je besoin". Je fait cela systematiquement sur mes machines DE PROD, et ca fout la trouille.
[^] # Re: nécessaire mais pas suffisant
Posté par Vivi (site web personnel) . Évalué à 5.
j'ai pas l'impression que ce soit le cas avec ma redhat 7.2
fait un rpm -q --requires XFree86-libs, tu veras, y'a pas XFree86.
Enfin pour l'export display il faut xauth (un client X11) qui ne s'installe pas sans serveur ...
pire que ça, il est dans le package du serveur. Pas super en effet.
Mais tu as raison, le problème ce sont les gros package genre perl, python, SDL.
Exemple: pour installer SDL-devel, il faut kde-libs-devel et donc kde-libs, etc.
[^] # Re: nécessaire mais pas suffisant
Posté par Dams Nadé (site web personnel) . Évalué à 2.
See :
XFree86-100dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-4.2.0-6.32.i686.rpm
XFree86-75dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-ISO8859-15-100dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-ISO8859-15-75dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-ISO8859-2-100dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-ISO8859-2-75dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-ISO8859-9-100dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-ISO8859-9-75dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-Xnest-4.2.0-6.32.i686.rpm
XFree86-Xvfb-4.2.0-6.32.i686.rpm
XFree86-base-fonts-4.2.0-6.32.i686.rpm
XFree86-cyrillic-fonts-4.2.0-6.32.i686.rpm
XFree86-devel-4.2.0-6.32.i686.rpm
XFree86-doc-4.2.0-6.32.i686.rpm
XFree86-font-utils-4.2.0-6.32.i686.rpm
XFree86-libs-4.2.0-6.32.i686.rpm
XFree86-tools-4.2.0-6.32.i686.rpm
XFree86-truetype-fonts-4.2.0-6.32.i686.rpm
XFree86-twm-4.2.0-6.32.i686.rpm
XFree86-xdm-4.2.0-6.32.i686.rpm
XFree86-xf86cfg-4.2.0-6.32.i686.rpm
XFree86-xfs-4.2.0-6.32.i686.rpm
XFree86-xtrap-clients-4.2.0-6.32.i686.rpm
Ca fait clairement pluss de packages mais ca permet d'affiner l'installation...
[^] # Re: nécessaire mais pas suffisant
Posté par richard bonichon . Évalué à 1.
quoi kde-libs en dependances pour sdl chez RedHat????? je vois pas le rapport...mais bon...ils doivent trainer avec les developpeurs du Hurd chez RedHat :-))
paske bon avec un rapide apt-cache show libsdl1.2-dev , on obtient...
Depends: libsdl1.2debian (= 1.2.2-3.4), xlibs-dev
et ca semble plus logique (et garantie sans sans troll sur les distribs...et autres)
@ +
[^] # Re: nécessaire mais pas suffisant
Posté par Vivi (site web personnel) . Évalué à 2.
dans le bazar son de SDL, y'a ce qu'il faut pour fonctionner avec arts (et avec esound aussi d'ailleurs). Donc SDL-devel a besoin des headers arts qui sont dans kdelibs-sound-devel qui a besoin de kdelibs et kdelibs-devel. Voilà youpi.
[^] # Re: nécessaire mais pas suffisant
Posté par William Steve Applegate (site web personnel) . Évalué à 10.
Ainsi, basesystem demande que j'installe (entre autres) ntsysv (des fois que je sache pas utiliser chkconfig), procmail (euh ?), isapnptools (mais j'ai pas de carte ISA !), les shells ash et sash, ainsi que etcskel et rootfiles (les fichiers de base dans /etc/skel et dans /root dont je ne veux pas). On a aussi besoin de mkbootdisk (sur une machine sans lecteur de disquettes... Madonna mia !) qui demande dosfstools (mais c'est quoi ce truc, je suis chez les fous ? !).
On continue notre exploration : j'aime pas kudzu, je connais le matos de ma machine, hop rpm -e kudzu. Ah oui, mais dynamic en a besoin. Ah. Mais euh, c'est quoi, dynamic ? rpm -qi -> « Create desktop entries for GNOME and KDE when a new peripheral is plugged in the system ». Bon, poubelle ! Ah, mais non, parce qu'il est nécessaire pour... devfsd ? ! ? C'est une blague ? Comment le démon devfs pourrait-il avoir *besoin* d'un machin pour mettre des jolies icônes de disques dans GNOME ? Encore un autre truc marrant : si vous désinstallez chkfontpath avant de virer des rpm contenant des fontes, leurs scripts n'arriveront plus à s'exécuter (oh, quelle surprise ! Et elle était où la dépendance ?)...
Et c'est comme ça en permanence... des dizaines de trucs sont là qui ne servent à rien à part apporter à des sKr1p7 k1dd13Z des moyens supplémentaires de placer un expl01t... c'est saoûlant ! Et parfois c'est bien pire. Par exemple, quand deux programmes ont des dépendances conflictuelles (genre toto veut libfoo mais Titi a besoin de libbar et libfoo ne veut pas s'installer si libbar est présente... Aaaargghh !). Bref, c'est du nawak.
J'aimerais ici donner mon avis : le boulot d'un admin, c'est pas de se battre contre ses machines pour un truc aussi simple que leur installer des softs. Une install, ça doit pas être un calvaire à la Windows, ça doit être une commande simple (« apt-get install apache » est une commande simple). On ne doit pas non plus avoir à garder sur la machine des softs qui ne servent à rien. Sous Debian (désolé, je parle de Debian parce c'est celle que j'utilise, c'est pas un troll), si un package est important mais pas strictement *nécessaire*, il est dans les Suggests:, pas dans les Depends: ! J'aimerais bien voir la même chose sous RH/Mdk. Urpmi est très bien mais si les dépendances sont foireuses, on va continuer à avoir des problèmes...
Envoyé depuis mon PDP 11/70
[^] # Re: nécessaire mais pas suffisant
Posté par jeanmarc . Évalué à -1.
Les rpmistes (surtout les mdkistes) reprochent souvent aux débianistes de se la jouer mais ils ont exactement la même attitude!
Quand je vois la news, je me demande qu'est-ce qui empêchait core de présenter le document expliquant urpmi sans la jouer "nananére, nous aussi on fait pareil". C'est super puéril.
L'une des notions qui arrive en tête dans le mouvement des logiciels libres, c'est l'entraide. Tu as d'abord toutes les sources à ta disposition, tu peux bien souvent poser des questions à l'auteur en lui envoyant un simple mail ou utiliser l'une des nombreuses mailing listes.
Ici, on constate que mandrake a copié de a à z le principe d'apt-get mais quand il s'agit de faire un utilisateur le reconnaître, y'a plus personne. C'est plutôt: "urpmi est mieux que apt-get parce qu'il est plus simple. Il faut faire urpmi xeyes au lieu d'apt-get install xeyes.". Officiellement non plus, mandrake ou redhat ne renvoient pas trop l'ascenseur vers le système qui a créé l'outil originel.
Quand j'ai appris que connective avait rendu apt-get compatible avec les rpms, j'étais content et je me demandais pourquoi ils ne l'avaient pas fait plus tôt!
Seulement, apt-get n'est pas un outil isolé. Il fait parti d'un tout qui a plusieurs années de réflexion et de travail acharné à son actif. Ce qui est intéressant, ce n'est pas uniquement de faire apt-get install exim mais qu'aprés avoir fait ça, on te propose de configurer, en te guidant, ton serveur de mail.
Quand tu fais apt-get install xsnow, on te suggére d'installer un serveur X avec mais tu n'es pas obligé de le faire.
Je pense qu'il y a encore beaucoup de boulot à faire au niveau du format rpm et des dépendances pour que des outils comme up2date et urpmi (qui sont trés jeunes) soient vraiment efficaces surtout en environment serveur. Mais le plus gros boulot reste au niveau de la mentalité des utilisateurs qui, au lieu de se réjouir, veulent absolument rabaisser le voisin qui ne leur a rien demandé.
[^] # Re: nécessaire mais pas suffisant
Posté par Prosper . Évalué à 2.
la premiere release est du 15 Novembre 1999 ( j appelle pas ca jeune )
quand a mandrake qui ne renvoit pas l ascenseur , dans la description d urpmi
http://www.linux-mandrake.com/en/82.php(...) il est qd meme dit que urpmi est un apt-like.
[^] # Re: nécessaire mais pas suffisant
Posté par jeanmarc . Évalué à -1.
Ca dépend énormément du nombre de personnes qui ont travaillé dessus.
>Improved URPMI (apt-like package manager) and Software Manager
C'est pas trés explicite apt-like. Surtout sur une page destinée aux nouveaux utilisateurs linux.
[^] # Re: nécessaire mais pas suffisant
Posté par Prosper . Évalué à 5.
[^] # Re: nécessaire mais pas suffisant
Posté par jeanmarc . Évalué à 0.
Un développeur a décidé de packager harddrake pour debian, d'où la présence de la lib dans la distrib. On peut le trouver ici: http://torsion.org/witten/debian/(...) mais ce n'est pas encore trés utilisable malheureusement.
>C est plutot vu comme la reconnaissance d un outil ( puisque les autres le prenne ca peut etre que bien ? :)
Là, c'est ton opinion que tu donnes ou la position officielle de mdk que tu nous livre?
De plus, ce genre d'affirmation n'est pas toujours vraie. Enormément de monde utilise office et pourtant, on ne peut pas dire que l'outil soit bien pour autant.
Je suppose que les gens de mdk réagissent comme tous ceux qui ont fait le choix de publier leur code sous licence GPL.
[^] # La différence entre RPM et DEB
Posté par maxoub . Évalué à 0.
[^] # Re: La différence entre RPM et DEB
Posté par Prosper . Évalué à 3.
[^] # Re: La différence entre RPM et DEB
Posté par jeanmarc . Évalué à 0.
Je dirait que les différences fondamentales viennent de l'interactivité à l'installation que possédent les .deb, les dépendances qui sont basées sur les fichiers chez les .rpm et sur les packages pour les .deb, la granularité en ce qui concerne les dépendances entre packages (depends, suggests, conflicts, replaces, provides,etc).
Le plus important est la politique de création du package car elle influe sur sa qualité.
Il y a prés de 900 mainteneurs officiels pour la debian d'où une certaine qualité. Les distributions commerciales ne peuvent pas mettre les mêmes ressources pour s'occuper de leurs packages (il n'y a qu'a voir le nombre de packets importants dont s'occupe le seul Chemlah chez mdk pour s'en rendre compte).
[^] # Re: La différence entre RPM et DEB
Posté par Prosper . Évalué à 3.
Tu parles des packages deb ou des rpms ?
Parce dans un package rpm tu peux sans probleme mettre les tags requires , buildrequires , conflicts , obsolete et provides .
(il n'y a qu'a voir le nombre de packets importants dont s'occupe le seul Chemlah chez mdk pour s'en rendre compte).
Chmouel plutot.
[^] # Re: La différence entre RPM et DEB
Posté par Ashimaru Cobaye . Évalué à 2.
[^] # Re: La différence entre RPM et DEB
Posté par jeanmarc . Évalué à -1.
>Parce dans un package rpm tu peux sans probleme mettre les tags requires , buildrequires , conflicts , obsolete et provides .
Je parle des debs et quand je dis "taguer" un package, il s'agit d'un package déjà installé sur le système. Celà n'a rien à voir avec la possibilité de lier un package à d'autre ou pas avant son installation.
>Chmouel plutot.
Autant pour moi. Toujours est-il qu'il doit avoir un trés trés bon salaire et pas mal d'actions mdk, ce mec! Je suppose qu'il est interdit de bagnole, de ski, de fête foraine ou tout autre truc qui pourrait être dangereux pour lui.
[^] # Re: nécessaire mais pas suffisant
Posté par YaP . Évalué à -1.
tu critique core mais on dirais que tu t'amuse bcp c temps cis à chaque news concernant de près ou de loin mandrake tu rapplique pour démontrer pas a +b que debian c bien et que mdk c nul et la tu devient exactement comme on dit plus haut.
j'en viens donc a me demander si la seule chose que vous connaissez c apt-get parce k'a part ca ya rien de si extraordinaire que ca dans la debian.
un ex: quand on installe X c vrai debconf le configure mais quand on change de carte graphique hein... sous mdk ya kudzu ki la détecte et ki nous permet de tout reconfigurer (ki a été introduit dans la debian depuis peu mais il semble pas encore aussi au point)
mais bon peut etre que ca à changer depuis...... (au fait vous attendez koi pour sortir une nouvelle version stable le kernel 2.6???)
[^] # Re: nécessaire mais pas suffisant
Posté par jeanmarc . Évalué à 1.
Il est clair que les mandrakistes sont plus nombreux sur linuxfr que toutes les autres distribs réunies! Il suffit de voir le nombre de [-] que tu te prends quand tu n'est pas pour la mdk et comparer avec le nombre de [+] qu'un mec se prend quand il ponctue son post dénué d'arguments d'un superbe: debian sux!
J'essaye de rétablir beaucoup d'approximations et d'abérations qu'on ne manque pas d'entendre sur la debian étant donné que la plupart des gens ici qui la descende ne l'ont jamais installée. Idem pour les autres distribs! Beaucoup crient: "suse c'est de la merde" ou "redhat, ça pue" s'en y avoir jamais touché!
Concernant ton post:
Moi, quand j'achéte une carte graphique, je connais le modéle. Je ne la prend pas les yeux fermés. Ensuite, arrivé chez moi, je ne vois vraiment pas la difficultée de taper dpkg-reconfigure xserver-xfree86 et de choisir ma carte dans un menu déroulant. C'est vrai que kudzu le fait pour toi mais, si tu ne sais pas comment ça marche derrière, le jour où sa foire, t'es bien incapable de te débrouiller tout seul! Ce que je trouve domage dans la mandrake, c'est qu'elle retire le côté didactique de linux. On se croirait retourné au temps de windows où tout était caché, qu'il fallait clickoter un peu partout et qu'on s'émerveillait pour un rien. Je vois ici que beaucoup pensent que c'est la mandrake qui reconnait plus de périphériques parce qu'elle a plus de drivers alors que c'est le kernel qui contient la plupart des drivers. C'est plus difficile par la suite d'avoir une vision réelle de ce qu'est linux par la suite. Je parle là pour les newbies qui sont la cible première et le coeur du marché de mdk. Les plus expérimentés peuvent en faire ce qu'ils veulent puisque c'est une distribution linux.
Je ne prend pas mon pieds à intervenir dans les news mdk mais je trouve qu'il reigne un mauvais esprit dans la communauté mdk et on ne s'en apperçoit pas de l'intérieur tant que son jugement n'a pas été remis en question de façon convaincante.
Par exemple, cette news est effarente! On sent vraiment le réglement de compte, le sous-entendu et les mauvais sentiments à l'égard des autres distribs!
>une des plus belles contributions de MandrakeSoft au Libre : l'outil URPMI
Là, on voudrait nous faire croire que mdk à inventé l'outil absolu qui va sauver le monde du libre à qui ils l'offre gracieusement alors que c'est une repompée totale de apt-get à la sauce rpm que debian offre à la communauté depuis des années!
>une utilisation avec une distribution non-Mandrake qui utilise RPM (comme Red Hat ou SuSE)
Là, c'est plus subtil mais c'est auusi trés fort! Les autres distributions ne sont pas mandrake-compatibles! Mandrake est donc un standard mais on peut quand même utiliser urpmi sur les autres distribs moyennes comme redhat et suse pour leur apporter la lumière.
Concernant ton troll sur la sortie de la prochaine debian, je te ferais remarquer que les gens de debian n'ont pas peur d'annoncer la couleur. Ils sortiront une version STABLE! D'ici là, la mdk en sera peut-être à la 12.3 mais la debian sera STABLE! Aller plus vite que la musique s'est souvent retourné contre mandrake.
[^] # Re: nécessaire mais pas suffisant
Posté par Prosper . Évalué à 5.
C est marrant , y a pas longtemps j aurait dit le contraire , rien que les mots debian ro><or dans un commentaire faisait que ce dernier etait scoré positif.
Moi, quand j'achéte une carte graphique, je connais le modéle. Je ne la prend pas les yeux fermés. Ensuite, arrivé chez moi, je ne vois vraiment pas la difficultée de taper dpkg-reconfigure xserver-xfree86 et de choisir ma carte dans un menu déroulant. C'est vrai que kudzu le fait pour toi mais, si tu ne sais pas comment ça marche derrière, le jour où sa foire, t'es bien incapable de te débrouiller tout seul! Ce que je trouve domage dans la mandrake, c'est qu'elle retire le côté didactique de linux
Je vois pas vraiment ou tu veux en venir , dans les 2 cas tu passes par un mode interactif , donc c est pareil si tu passes par debconf , c est pas pour cela que tu sauras configurer a la mano un XF86Config.
On se croirait retourné au temps de windows où tout était caché
Les outils de conf mandrake sont des front-end pour configurer des fichiers de conf texte
qui sont sans probleme accessible avec vi !
Ca me fait penser a un post sur debian-french ou une personne affirmait que les fichiers de configuration mandrake etait des binaires
Je vois ici que beaucoup pensent que c'est la mandrake qui reconnait plus de périphériques parce qu'elle a plus de drivers alors que c'est le kernel qui contient la plupart des drivers
c est pas seulement une histoire de kernel , encore faut il un kernel qui contient les nombreux drivers , et surtout une correspondance pci-ID<-> module avec les options et la conf qui vont bien ( idem pour isa , usb, xfree...)
là, c'est plus subtil mais c'est auusi trés fort! Les autres distributions ne sont pas mandrake-compatibles! Mandrake est donc un standard mais on peut quand même utiliser urpmi sur les autres distribs moyennes comme redhat et suse pour leur apporter la lumière.
Je crois pas que ce soit ce qu il ait voulu dire .
C est pas installer les rpms mandrake sur une autre distrib , mais plutot installer urpmi et rpmtools puis generer une hdlist pour urpmi sur une liste de rpm de la distrib (genre mettre urpmi sur redhat et construire la hdlist sur les rpms redhat )
[^] # Re: nécessaire mais pas suffisant
Posté par jeanmarc . Évalué à -1.
Les temps changent malheureusement pour nous :-(
>Je vois pas vraiment ou tu veux en venir , dans les 2 cas tu passes par un mode interactif , donc c est pareil si tu passes >par debconf , c est pas pour cela que tu sauras configurer a la mano un XF86Config.
Quand Kudzu détecte ta carte, il te demande si tu veux la configurer, combien de couleurs tu veux,etc.
Quand debconf configure xfree, il te demande si tu veux qu'il prenne en charge la configuration du fichier XF86Config-4. Il te pose les questions sur ta carte avec des explications et quand tout celà est fait, il te demande s'il peut modifier le fichier XF86Config-4. Tu en apprends vachement plus de cette façon. C'est ce que je voulais dire. Tu sais au minimum quel fichier modifier.
>Les outils de conf mandrake sont des front-end pour configurer des fichiers de conf texte
>qui sont sans probleme accessible avec vi !
ou avec n'importe quel éditeur de texte. Le but de la mandrake est quand même d'être le pus user-friendly possible et je ne crois pas que les gens de mandrake se réfutent le fait qu'ils s'attaquent aux nouveaux venus sous linux. Je vois mal ces gens lancer leur vi pour éditer un fichier de conf! Tout est fait pour qu'il n'ait jamais à le faire même s'il peut le faire contrairement à windows.
>Ca me fait penser a un post sur debian-french ou une personne affirmait que les fichiers de configuration mandrake etait des >binaires
N'essaye pas de me discréditer avec ce genre d'allusion. Des arguments stp. Personnellement, j'évite de parler de ce que je connais pas. J'ai longtemps utilisé mdk sur un portable et je continue à regarder ce qui se passe de leur côter pour ensuite pouvoir comparer et juger. Beaucoup ici n'ont jamais intallé autre chose qu'une mdk mais se permettent de juger les autres distribs.
>Je crois pas que ce soit ce qu il ait voulu dire .
Ce n'est pas dit de la plus claire des manières si c'est ce qu'il a voulu dire. De toute façon, il n'y a que l'auteur pour infirmer ou non.
# Redhat et apt-get..
Posté par Dams Nadé (site web personnel) . Évalué à 4.
RedHat fourni up2date. Vous pouvez enregistrer 1 machine gratuitement sur le "Red Hat Network" et apres utiliser up2date pour installer des packages avec leurs dependances a coup de "up2date machin-pwet".
Cela dit sur http://enigma.freshrpms.net/(...) y'a un rpm de apt-get preconfigure' pour avoir freshrpms et tuxfamily dans le sources.list..
[^] # Re: Redhat et apt-get..
Posté par Antoine Beck . Évalué à 7.
J'ai 2 machines (une au boulot, l'autre chez moi) qui n'ont pas tout à fait les même packages d'installé, et bien la maj avec apt-get upgrade c'est faite sans problème. Sur ma machine j'avais remplacé le sendmail par postfix et il n'y a pas eu de souci.
Le système proposé par RH (up2date) je ne sais pas si ça fonctionne pareil puisque jamais utilisé, mais je vois au moins une restriction : il faut s'enregistrer...
# C'est avant tout MDK non ?
Posté par bib . Évalué à 1.
Je ne suis pas certain que ce soit si facile d'approche que cela ou que ce soit la panacée. En effet, demander un débutant s'il veut désinstaller ça ou ça, peut-être ennuyeux.
Je pense qu'il peut se retrouver avec un système non pas instable mais plutôt incomplet ou surchargé... Donc, c'est bien mais ça a le défault d'éviter de mettre un minimum de "le nez dans le cambui", ce qui empêche d'en apprendre un peu.
A noter aussi, que j'ai découvert plusieurs sites de RPMs alternatifs (divx, mplayer, ripper, etc) utilisant des bases hdlists pour urpmi, c'est encourrageant et c'est un trés bon complement à la mdk full gpl (ou légal).
[^] # Re: C'est avant tout MDK non ?
Posté par Prosper . Évalué à 9.
C'est pourtant un des arguments donnés lorqu'on met en avant une debian , toujours le :"pi d abord sur debian c est facile , y a apété-gaite"
# Rousse
Posté par V . Évalué à -4.
[^] # Re: Rousse
Posté par Pascal Terjan (site web personnel) . Évalué à 4.
Copyright (C) 2001 Guillaume Rousse
Permission vous est donné de distribuer de copier, distribuer et/ou modifier ce document selon les termes de la GNU Free Documentation License, version 1.1 ou n'importe quelle autre version ultérieure publiée par la Free Software Foundation.
Une copie de la license peut être consultée ici.
Et son nom est sur pas mal d'autres pages...
Quel est ton problème ?
[^] # Re: Rousse
Posté par Aza . Évalué à 1.
[^] # Re: Rousse
Posté par Ashimaru Cobaye . Évalué à -1.
# Hey !
Posté par Denis Bodor (site web personnel) . Évalué à 2.
Personne n'a jamais dit systématiquement qu'une ou l'autre solution était la meilleurs. D'ailleurs, tant qu'à faire, je signalerai que dans le dernier LM il y a un article sur urpmi et un autre sur apt-get sur RedHat.
J'avous ne pas bien comprendre pourquoi il t'es nécessaire de glissser une référence à LinuxMag pour signaler qu'il existe urpmi et apt-get rpm.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.