Distribution : Sortie de la Mandriva Linux 2008.1 Spring
Posté par Sylvain Rampacek (Jabber id, page perso, ). Modéré le 10 avril 2008.
Au menu de cette nouvelle mouture, on peut citer le prise en charge complète de l'Asus EEE PC, la possibilité de synchroniser les logiciels d'agenda avec la plupart des PDA (incluant Windows Mobile 5 et supérieur, ainsi que les Blackberry et les téléphones Nokia). Elle inclut également un gestionnaire de codecs pour les applications multimédias (Codeina). KDE y est en version 3.5.9 et la version 4.0.3 est disponible sur les miroirs officiels. GNOME quant à lui est en version 2.22. Enfin, on y retrouvera également OpenOffice.org en version 2.4, le noyau Linux 2.6.24.4, X.org 7.3, Compiz 0.7, et bien d'autres !
Si l'installation vous fait peur, la version One (sur un live-CD) est également disponible (une version spéciale KDE ou une version GNOME, au choix, sont disponibles).
![[fr]](../images/fr.png)
L'annonce de la sortie de la 2008.1 Spring (1467 hits)-
La page sur le wiki de mandriva pour la 2008.1 (870 hits)
-
Le test de la RC2 (680 hits)
![[en]](../images/en.png)
Mandriva Linux 2008.1 en images (1197 hits)
> Lire la dépêche (160 commentaires, moyenne: 3).
Vous avez demandé le commentaire #921556.
Run by 
Cette page a été générée par Templeet en 0.2945s (dont 0.0332 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
[+] dommage
Dommage que Mandriva s'obstine à utiliser les rpm de RedHat. Ça lui coute cher finalement d'avoir tout pompé sur la mauvaise distribution pour finir par utiliser un horrible gestionnaire de packets franchement limité.
Dommage aussi qu'il faille payer pour disposer de la version complète et des forums.
Dommage enfin qu'elle soient si laide et mal configuré et que les outils de configuration, qui sont propriétaires, soient aussi instables et envahissants.
De toute façon, c'est la plus mauvaise distrib que je connaisse. La dernière fois que j'ai essayé de l'installer, elle m'a grillé 2 disques dur et un lecteur DVD. Sans compter que j'ai chopé un lumbago.
Les dev feraient bien de se remettre au travail et de s'inspirer d'une vraie distrib comme Ubuntu !
[+] [^]Re: dommage
C'est tellement un ramassie de conneries ton post que j'ai même pas envie de la moinser
[^]Re: dommage
à mon avis c'est ironique, c'est beaucoup trop gros.
Hôdo
Livingstone
[^]Re: dommage
Ça sert à quoi que je me décarcasse si tu me casse la baraque ?
[^]Re: dommage
tu aurais pu être un peu plus fin quand même.
[^]Re: dommage
J'ai du faire vite. Un troll comme ça, faut que ça soit dans les tout premier commentaire, sinon c'est mort.
Et il ne se porte pas si mal que ça tout de même.
[^]Re: dommage
Là je dis: félicitations! Parce que, même en annonçant la couleur et en criant au troll à tue-tête, ça marche quand-même à tout berzingue... Au final, il ne t'a même pas cassé ton coup!
Respects :-) .
[+] [^]Re: dommage
>C'est tellement un ramassie de conneries ton post que j'ai même pas envie de la moinser
Si tu avançais des arguments de critiques gratuites ?
[^]Re: dommage
Hé!
On avait pas dit qu'on trollait sur le journal de sa sortie, et qu'on gardait les commentaires pertinents sur la dépêche?
Surtout qu'on n'est pas vendredi!
Du coup je sais plus où poster, moi!
[^]Re: dommage
>On avait pas dit qu'on trollait sur le journal de sa sortie, et qu'on gardait les commentaires pertinents sur la dépêche?
Ben oui :-)
[^]C'est pour la télé ?
Je suppose que c'est une tentative d'obtenir la note la plus basse possible :-)
--- Dans un restaurant, Chuck Norris a commandé un steak. Le steak a obéi --
[^]Re: C'est pour la télé ?
Le -10 est atteint... ça n'a pas l'air de descendre plus bas.
(pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)
[^]Re: dommage
Je me doute que ça sent le troll mais je ne peux pas m'empêcher de répondre parce que si on ne répond pas (ou juste en disant que c'est un troll) au final ça ne vaut pas vraiment le coup et le lecteur reste sur les idées qu'il a lues.
La gestion des rpm à travers rpmdrake est largement satisfaisante pour moi. Rpmdrake n'a cessé de progresser depuis plusieurs versions aussi bien en ergonomie qu'en rapidité. Quant au débat entre .deb et .rpm je dois avouer ma totale incompétence d'une part n'étant pas développeur et d'autre part n'utilisant pas de distribution à base de .deb pour pouvoir comparer objectivement sur la facilité d'emploi.
Le forum officiel est totalement gratuit depuis pas mal de temps, l'inscription est gratuite et tout le monde peut intervenir librement, y compris pour critiquer Mandriva, la distribution, la société.
Les outils de configuration sont sous licence GPL, stable de mon point de vue et utilisable aussi bien avec que sans interface graphique (ce qui est très pratique pour remettre d'aplomb la configuration du serveur X avec XFdrake sans avoir besoin de bidouiller un fichier de configuration dans la console). L'aspect visuel est du goût de chacun, certains apprécient le bleu, d'autres le vert ou le marron.
Elle mérite le coup d'œil et de mon point de vue elle rend l'utilisation de Linux très facile et permet de se passer de toute ligne de commande pour se faire oublier et se consacrer à l'utilisation de son ordinateur et non à la maintenance de son système d'exploitation.
Maintenant on peut débattre ou troller sur des bases sérieuses ;)
Ce n'est pas parce que les choses sont difficiles que nous n'osons pas, c'est parce que nous n'osons pas que les choses sont difficiles - Sénèque
[^]Re: dommage
On sait que le débat rpm/deb est un débat stérile (du point de vue du Jean-Kevin, j'entends) sauf dans l'étude approfondie des choses, et là on se rend compte que les deux format sont côte à côte, à quelques fonctionnalités poussées près... C'est un peu comme comparer des perfo bosh et b&d.
Mais et le lumbago ? hein ? hein ?
Il n'est toujours pas prouvé que mandriva n'est pas responsable des lumbagos ;)
Hôdo
Livingstone
[^]Re: dommage
Non je t'assure, Bosch c'est beaucoup plus mieux de Black & Decker puisque je le dis :-)
[^]Re: dommage
Pas du tout, efface ! Il vaut mieux l'avoir Black & Decker que blanche et molle.
[+] [^]Re: dommage
Ça lui coute cher finalement d'avoir tout pompé sur la mauvaise distribution pour finir par utiliser un horrible gestionnaire de packets franchement limité.
Je ne suis pas non plus un adepte du gestionnaire de paquets RPM, lui préférant APT que je trouve plus souple et plus pratique. Mais loin de moi l'idée de lancer le débat.
Je profite de ce point pour m'informer su le projet Autopackage http://autopackage.org.
Qu'en est il de son intégration dans les différentes distributions ? et surtout de son usage chez les différents mainteneurs de paquet ... ?
Certaines personnes auraient de l'info ? Je sais que ce n'est pas vraiment le lieu m'enfin, vous pourriez m'accorder quelques liens et avis ... :D
blog.collign.net
[^]Re: dommage
> Je ne suis pas non plus un adepte du gestionnaire de paquets RPM, lui préférant APT que je trouve plus souple et plus pratique
Déjà première erreur, l'équivalent de RPM ce n'est pas APT mais dpkg.
RPM et dpkg sont des système de gestion de paquets, yum/urpmi et apt-get/aptitude sont des systèmes avancés de gestion de paquets qui se basent respectivement sur les systèmes précédemment cités.
Deuxième erreur, si pendant longtemps apt-get est resté sans véritable équivalent dans le monde RPM, c'est chose révolue avec yum (et je suppose actuellement urpmi)
Sinon, dpkg et RPM sont plus ou moins équivalent, chacun ayant des fonctionnalités avancés que l'autre n'a pas.
[^]Re: dommage
Déjà première erreur, l'équivalent de RPM ce n'est pas APT mais dpkg.
Merci pour la correction, c'est une erreur grossière.
Deuxième erreur, si pendant longtemps apt-get est resté sans véritable équivalent dans le monde RPM, c'est chose révolue avec yum (et je suppose actuellement urpmi)
Je ne vais pas donner mon avis ici, on va dire que je troll. :D
blog.collign.net
[^]Re: dommage
> yum/urpmi et apt-get/aptitude sont des systèmes avancés de gestion de paquets
Mouaif...
rpm/apt est bas-niveau. Ils connaissent le format des paquets (à quel offset est stocké telle ou telle information, etc), il fait tous les contrôles en toute fin, il lance les scripts d'installations, contrôle les conflits entre fichiers, c'est rpm qui fait la vérification de signature, etc.
Il y a largement plus de code pour rpm que pour yum.
Yum (ou autre) est "seulement" un utilisateur de rpm (ou librpm). Il n'est pas plus avancé que rpm. Il fait des choses que ne fait pas rpm. Des choses qui ne sont pas nécessaire pour l'outil de bas niveau. Par exemple downloader les paquets, ajouter automatiquement un paquet s'il y a une dépendance, etc.
En passant, rpm avait la gestion automatique de dépendance. Ça utilisait rpmdb (qui n'est plus fournit). La fonctionnalité, si elle existe encore, n'est pas supportée.
[^]Re: dommage
Deuxième erreur, si pendant longtemps apt-get est resté sans véritable équivalent dans le monde RPM, c'est chose révolue avec yum (et je suppose actuellement urpmi)
tu aurais du mettre cela dans le journal spécial troll
[^]Re: dommage
> tu aurais du mettre cela dans le journal spécial troll
A part la réputation de deb, il y a quoi de formidable dans deb ?
Deb vient d'avoir les trigger alors que ça existe depuis des lustres sous rpm. En passant, c'est spécifique Ubuntu. Rpm supporte les systèmes bi-arch (i386/x86_64). Rpm a la signature (GPG) des paquets depuis des lustes alors que dpkg depuis quelques mois.
Il y a un truc qu'a deb et non rpm, c'est les suggestions.
> tu aurais du mettre cela dans le journal spécial troll
Fait un journal qui démontre la supériorité de deb sur rpm.
Fait de même pour apt et yum si tu veux.
[^]Re: dommage
Je pense que ce que Stephane veut dire, c'est que les problemes de dependances avec rpm ne sont pas "revolus" (si tant est que le terme de "revolu" a une connotation de "recemment resolu") mais qu'ils n'existent plus depuis belle lurette. Je me souviens avoir utilise urpmi des 1998, et qu'il remplissait deja bien une fonction equivalente a apt (en telechargeant et installant les dependances a partir des listes sur les depots de paquets).
[^]Re: dommage
Cette incompréhension chronique de ce qu'est RPM est quelque peu exaspérante. Il faut comprendre que :
- rpm gère les paquets, mais pas leurs dépendances.
- urpmi est une surcouche à rpm qui gère les dépendances.
- rpmdrake est une surcouche graphique à urpmi
Ce schéma est volontairement simplifié. Le comprendre devrait permettre d'éviter de dire des bêtises.
Il y a aussi l'applet "Mandrake On line" qui 'appuie sur urpmi et permet de mettre la distribution à jour d'un seul clic !
En ligne de commande
urpmi.update -a && urpmi --auto-selectfait la même chose.La gestion de paquets de Mandriva n'a rien à envier aux autres distributions, bien au contraire !
[^]Re: dommage
"urpmi --auto-update" remplace "urpmi.update -a && urpmi --auto-select"
[^]Re: dommage
> - rpm gère les paquets, mais pas leurs dépendances.
rpm gère les dépendances !
Ce que ne fait pas rpm, c'est les résoudre automatiquement.
[+] [^]Re: dommage
C'est juste debian qui a inventé les .deb, alors vu que debian caybien, trucbuntu caymieux et mandriva caca.
Faut pas chercher loin
[^]Re: dommage
Il y a un truc qu'a deb et non rpm, c'est les suggestions.
Faux, rpm gère les suggestions : Suggests: dans les fichiers spec
[^]Re: dommage
T'es sûr ?
Car je crois que Jeff Johnson avait proposé ça assez tard (année 2007) et que rpm (rpm.org) l'a refusé. Par contre rpm de Jeff Johnson (rpm5.org) l'a peut-être.
Il me semble que conectiva était contre et Fedora est contre aussi. En passant, Fedora a les groupes (fichier comps.xml) depuis des lustes. Ce qui limite l'intérêt des suggestions.
Les groupes sont gérés par yum (et ses fils graphiques).
Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.
[^]Re: dommage
Certain, c'est utilisé par urpmi depuis la 2007.0 ou 2007.1 je crois, en tout cas je l'ai utilisé dans des paquets depuis la 2008.0.
J'ai jeté un coup d'oeil, et à priori c'est implémenté dans rpm depuis 2005.
Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.
Bah si c'est leur position, je trouve ça ridicule, s'il ne veulent pas d'un Suggest: xxxx, ils n'ont qu'à pas le mettre dans leur spec. A ce moment là il faudrait qu'ils suppriment complètement la gestion des dépendances, certaines distributions pourraient avoir la politique de définir un Requires: adobe-flash pour reprendre ton exemple.
[^]Re: dommage
Certain, c'est utilisé par urpmi depuis la 2007.0 ou 2007.1 je crois, en tout cas je l'ai utilisé dans des paquets depuis la 2008.0.
J'ai jeté un coup d'oeil, et à priori c'est implémenté dans rpm depuis 2005.
Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.
Bah si c'est leur position, je trouve ça ridicule, s'il ne veulent pas d'un Suggest: xxxx, ils n'ont qu'à pas le mettre dans leur spec. A ce moment là il faudrait qu'ils suppriment complètement la gestion des dépendances, certaines distributions pourraient avoir la politique de définir un Requires: adobe-flash pour reprendre ton exemple.
[^]Re: dommage
> A ce moment là il faudrait qu'ils suppriment complètement la gestion des dépendances
Ne soit pas débile.
> certaines distributions pourraient avoir la politique de définir un Requires: adobe-flash pour reprendre ton exemple.
Es-ce que Firefox nécessite adobe-flash ?
Non.
Chaqu'un est libre de violer rpm. Des cons il y en aura toujours.
[^]Re: dommage
Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.
Et alors je ne vois pas le problème, si mandriva dans son paquet firefox veut y inclure une dépendance molle vers flash, je ne vois pas en quoi ça impacte Suse/Fedora/... Qui, autant que je le sache font leurs propres fichier spec et donc y mettent ce qu'ils veulent.
[^]Re: dommage
Rpm répond à un problème technique.
Il n'est pas politique.
> Qui, autant que je le sache font leurs propres fichier spec et donc y mettent ce qu'ils veulent.
Oui. Mais un rpm n'est pas forcément fait pour et par une distribution. Certains rpms (lsb compatible) peuvent être installer partout.
Et si je veux l'installer, je ne veux pas qu'il me sugère flash d'adobe. Le boulot de rpm, c'est (entre autre) l'installation des programmes. Pas un truc pour faire de la pub à flash d'adobe.
[^]Re: dommage
Et pourquoi pas un noyau qui suggère le driver proprio de NVidia s'il détecte une carte NVidia...
L'horreur...
[^]Re: dommage
Aucun rapport avec rpm, a moins que le script d'install d'un rpm puisse modifier à la volée les dépendances du rpm dont il fait partie, fonctionnalité potentiellement intéressante mais non implémentée autant que je le sache
[^]Re: dommage
> a moins que le script d'install d'un rpm puisse modifier à la volée les dépendances du rpm dont il fait partie, fonctionnalité potentiellement intéressante mais non implémentée autant que je le sache
Je ne vois pas le rapport.
[^]Re: dommage
Je ne vois pas d'autre moyen pour que le rpm d'install du noyau te suggère le module nvidia si tu as une CG nvidia (ou alors il faut que tu m'explique comment tu fais ta détection de CG)
[^]Re: dommage
Je vois bcp d'autres moyens de faire çà a un autre niveau. Le niveau idéal est le meta gestionnaire de paquet non pas la couche bas niveau dont le boulot doit être réduit à son minimum, à savoir packager un logiciel sans autre forme de fioritures.
Small is beautiful, guys.
Le graphe de dépendances et de suggestions ne doit pas être gérer au niveau du logiciel de paquet, c'est de l'over engineering d'un logiciel çà.
a +.
[^]Re: dommage
OK.
Au chargement du module nv, il pourrait y avoir un message dans /var/log/message qui suggère le driver proprio.
Je suis contre ce principe.
Après du pourrait avoir Firefox qui suggère Gnome s'il ne trouve pas Gnome, etc.
C'est la (mauvaise) idée globale qu'il faut voir ici. Pas le côté technique.
[^]Re: dommage
enfin là t'es carrément sorti du cadre d'un gestionnaire de paquetage non ?
Pour tu donner un contre exemple, je te donnerai l'exemple du paquet task-kde sous la mandriva (2008.1 précisement)
si je veux installer le task-kde celui-ci me tire via un jeu de dépendance dures :
Kerry -> Beagle -> Mono -> ...
super !!!! Je voulais KDE et je me retrouve avec ce gros bloatware de mono. Alors qu'il aurait juste fallu avoir mis Kerry en suggest et hop ! Je peux garder mon task-kde (qui me facilite l'install de kde) sans avoir (trop) de cochonneries (Brevets / techno microsoft / MDI) d'installées sur ma machine
[^]Re: dommage
Avec les groupes dans un fichier xml comme dans un Fedora, tu as un système similaire. Dans un groupe, tu as les paquets essentiels et les paquets supplémentaires (ou suggérés).
L'avantage est que c'est plus souple à maintenir, je ne change qu'un fichier xml et non pas un fichier spec qui signifie recompilation du paquet, mise à jour inutile pour 99% des utilisateurs etc ..., si tu dois faire ça assez souvent, ça devient vite lourdingue. Les concepteurs de RPM ont fait choix, celui de laisser la gestion des groupes à l'outil de haut niveau.
Si tu veux un mécanisme de suggestions, il faut l'implémenter dans urpmi et non pas dans RPM.
[^]Re: dommage
Oui enfin tes suggests, tu les changes pas tous les 4 matins non plus, Une fois ta distrib sortie en version N, tu t'amuses pas à les changer (quelque soit sa manière d'être implémentée). Et les scripts de reconstruction nocturnes sont utilisés par à peu près toutes les distrib, donc c'est un faux probleme
[^]Re: dommage
> donc c'est un faux probleme
Ce n'est pas un faux problème.
Pour Fedora il y a :
- Fedora (full, avec evolution par défaut, etc)
- Fedora KDE (avec kmail par défaut, etc)
- Fedora Games
- Fedora Developers
- Fedora Electronic Lab
- Fedora XFCE
Il y a en peut-être d'autres. Toutes ses distributions utilisent les mêmes paquets rpm. On n'a pas à recompiler 6 (!) fois le même paquets. Gain de temps et d'espace disque (ose imaginer le cas de OOo).
> donc c'est un faux probleme
La place disque (sur les mirroirs) commence a être un sérieux problème.
[^]Re: dommage
Tout cela peut se gérer très facilement via un jeu de sources de paquets ( un peu à la manière d'ubuntu / kubuntu / ... ) qui partagent la même base et quelques meta paquetages (que tu n'aimes pas mais que que beaucoup de distrib utilisent, donc ce ne peut pas être entièrement mauvais).
Ton OOo il est dans un repository commun a toutes tes versions de Fedora, et eventuellement dans ton Fedora KDE tu y colles un paquet qui permet de KDEiser son interface pour qu'elle s'integre mieux dans KDE.
[^]Re: dommage
Admettons. En passant, je crois que tu mélanges avec un autre problème.
Mais vois comme cette "mauvaise" idée a rapidement des répercutions.
Es-ce que rpm doit encourager ce type de truc ?
Je ne crois pas.
Ceci dit, je pense avoir bien compris ton avis et que tu as bien compris le mien.
Donc j'arrête.
[^]Re: dommage
J'ajoute pour être clair, je ne suis pas contre le principe de suggérer ou des meta-paquets. Mais ça ne doit pas (à mon avis) être fait au niveau de rpm.
On peut voir que yum c'est étoffé avec des informations qui n'ont pas leur place dans rpm. Par exemple des informations qui indiquent si le paquet est un correctif de sécurité (pertinant pour une mise à jour, mais sans intérêt pour une nouvelle release). Cette informations est par rapport à l'ancien paquet et donc implique un "workflow" dont rpm est totalement étrangé. Donc cette information, aussi utile soit-elle, n'a pas à être dans rpm.
Ce n'est pas car une information est utile, qu'il faut la foutre n'importe où.
[^]Re: dommage
Ben cette pratique des meta-paquets n'est pas bonne à mon avis.
Je dis ça, c'est une news Mandriva, je vais me faire exploser et accuser d'insulter les développeurs, de chier sur ... etc...
Bref, je n'irais pas plus loins sauf pour dire qu'il y a des alternatives à ces meta-paquets.
[^]Re: dommage
dommage, on ne peux plusser qu' une fois
gnome / f-spot / mono > /dev/null
[^]Re: dommage
Je ne vois pas en quoi mettre en suggest (qui est une dépendance molle, donc optionnelle) dans un fichier spec est politique.
Tu prends le mauvais exemple d'une dépendance vers un lib proprio, alors qu'il pourrait y avoir des dizaines d'exemple concernant du pur libre (entre autres dans le multimedia).
Un package est toujours créé pour une version de distribution a cause des dépendances dures concernant des versions de bibliothèques par exemple, donc le fichier SPEC n'est pas écrit pour lsb mais pour une version précise de distribution, tout en tenant compte des recommandations lsb qui portent surtout sur des emplacements de fichier autant que je le sache.
Si le paquet rpm de mandriva qui tu voulais installer sur ta fedora te fais des suggestions qui te de plaisent, tu peux toujours :
- prendre un autre paquet : Suse / CentOS / ... en proposent ( Fedora aussi ;-) )
- refaire le paquet en virant le suggest a partir du src.rpm
- ignorer le suggest
Je trouve que c'est un choix plus que raisonnable.
[^]Re: dommage
Je ne suis pas contre les "dépendances molles" ou les suggestions.
Je dis seulement que ça ne doit pas être fait au niveau de rpm (qui est le plus bas niveau).
Fedora a des "dépendances molles", c'est traitée avec le fichier comps.xml. C'est dans ce fichier qu'on trouvera les décisions "politiques". Pas au plus bas niveau.
Le fichier comps.xml est au niveau de la distribution (et techniquement rien n'empêche de l'utiliser avec des .deb ou autre).
Au plus bas niveau on doit avoir le minimum de dépendance et ne pas faire de suggestion. Ça améliore la réutilisation.
> donc le fichier SPEC n'est pas écrit pour lsb
Ben parfois oui. Parfois il est fait pour plusieurs distributions.
Un exemple récent :
http://developer.amazonwebservices.com/connect/entry.jspa?ex(...)
Ce n'est pas fait spécifiquement pour une distribution.
Et après, que fais tu des suggestions ?
Même apt n'utilise pas ça à ma connaissance. Ça existe depuis des plombes, et ce n'est presque pas utilisé. C'est dire comme c'est une faux bonne idée.
[^]Re: dommage
Et après, que fais tu des suggestions ?
Simple, si elle ne sont pas disponibles, tu ne le propose même pas.
Sinon tu propose (après entre le opt-in et le opt-out ça c'est effectivement purement politique)
Le problème du comps.xml (que je ne connais pas vraiment) c'est que c'est géré au niveau de yum non ? Dans ce cas quid des autres distrib qui n'utilisent pas yum ? Elle est où la compatibilité inter distribution ?
[^]Re: dommage
> Elle est où la compatibilité inter distribution ?
Elle n'existe pas, c'est quasi intentionnel.
Ainsi tu peux avoir une distribution avec le bureau par Gnome défaut, une autre avec KDE, une autre avec evolution par défaut, une autre avec thunderbird, une autre qui installe tout Gnome et une autre qui installe que le minimum pour Gnome, etc.
comps.xml est spécifique à la distribution.
Par contre rpm ne l'est pas.
Les suggestions sont spécifiques à une distribution (à sa politique/philosophie), donc ils ne devraient pas être au niveau de rpm. Rpm s'occupe que de questions techniques.
[^]Re: dommage
rpm n'est pas spécifique à une distribution mais les fichiers spec le sont.
Je te rappelle que je ne plaide pour avoir l'obligation mais la possiblité d'utiliser le suggest, c'est tout à fait optionnel.
Libre après à chaque mainteneur de paquetage/distribution de l'utiliser selon ses goûts et ses envies.
Le "suggest" est une possiblité technique donc a tout à fait sa place dans rpm, c'est sa présence ou non et les dépendances qui s'y trouvent (autrement dit la manière de l'utiliser) qui est propre à une distribution.
[^]Re: dommage
> Le "suggest" est une possiblité technique donc a tout à fait sa place dans rpm
C'est comme les options en tout genre dans un bureau. C'est optionnel, mais ce n'est pas le lieu si on veut en faire un bureau pour beaucoup.
Après tu peux ajouter les résolutions automatiques (et optionnels) des dépendances, le choix du mirroir à utiliser (optionnel), l'interface graphique (optionnelle), etc.
Ce principe moux va à la catastrophe ou du moins est la voix royale au n'importe quoi.
Après le suggest, il y aura le suggested-doc (ça ne fait pas de mal, c'est optionnel), le suggested-skin (ça ne fait pas de mal, c'est optionnel), le suggested-ram (ça ne fait pas de mal, c'est optionnel), etc.
Ceci sucks dans les grandes largeurs.
Tu aimes ça, je n'aime pas ça, on ne sera pas d'accord.
> Le "suggest" est une possiblité technique donc a tout à fait sa place dans rpm
Ben il n'y est pas.
Et comme c'est une dépêche Mandriva, Mandriva ne l'utilise pas (puisque de toute manière ça n'existe pas).
[^]Re: dommage
> C'est comme les options en tout genre dans un bureau. C'est optionnel, mais ce n'est pas le lieu si on veut en faire un bureau pour beaucoup.
Mais non justement ça n'a rien à voir.
D'ailleurs pour prendre gnome en exemple (puisque c'est ce que penses je me doute), gnome a des options.
Seulement elles ne sont pas toutes visibles et pour certaines on ne peu y accéder que par gconf.
Mais les options sont là.
Ben là c'est pareil, rpm gère les requires, devrait gérer à mon sens les suggest (qui ne sont qu'une forme de dépendance, optionnel mais dépendance)
Et comme actuellement, c'est aux sur couches (urpmi, yum, ...) d'installer, proposer, etc, tenir compte de suggest ou non. Comme c'est fait actuellement si on a plusieurs paquets ayant le même provides par ex.
Ce que je ne comprend pas c'est surtout pourquoi dire non c'est pas bien (ou plutôt en vrai, non on en a pas besoin (pour fedora...) ) et par extension le refuser dans rpm alors que d'autres le voudraient...
Finalement je crois que je comprend pourquoi il y a un fork de rpm...
[^]Re: dommage
> D'ailleurs pour prendre gnome en exemple (puisque c'est ce que penses je me doute)
Bien vu.
Mais c'était une connerie de ma part.
Rpm a des objectifs (que) technique. Ce n'est pas le cas de Gnome.
> une forme de dépendance, optionnel mais dépendance
Une dépendance optionnelle n'est pas une dépendance.
Quand penses-tu ?
> Comme c'est fait actuellement si on a plusieurs paquets ayant le même provides par ex.
Je ne peux pas parler pour Mandriva, mais pour Fedora ce n'est pas fait comme ça.
J'ai Gnome comme bureau, je peux (et d'ailleurs je le fais) virer Nautilus. Le bureau Gnome ne dépend pas de Nautilus (mais Nautilus dépend de Gnome).
Et je "maudirais" rpm si un jour il me suggère d'installer Nautilus.
PS: ce n'est pas une critique de Nautilus, je n'utilise pas les gestionnaires de fichier graphique.
> Ce que je ne comprend pas c'est surtout pourquoi dire non c'est pas bien (ou plutôt en vrai, non on en a pas besoin (pour fedora...) ) et par extension le refuser dans rpm alors que d'autres le voudraient...
Je répète pour au moins la quatrième fois, je ne suis pas contre le concèpte de suggérer un autre paquet, mais je suis contre de le faire dans rpm.
A une époque Fedora "suggérait" epiphany comme navigateur. Puis ça été Firefox. Ben Fedora n'a pas besoin de recompiler les paquets pour ça. Comme ce n'est pas dans rpm, Fedora n'a pas un compiler des paquets pour Fedora saveur Gnome et Fedora saveur KDE et Fedora saveur developers, etc.
Je répète encore, je ne suis pas contre le concèpte de suggérer un autre paquet. Fedora, les faits le montre, n'y est pas contre non plus. Mais ça ne doit pas être fait dans rpm.
[^]Re: dommage
> Une dépendance optionnelle n'est pas une dépendance.
> Quand penses-tu ?
je dirais qu'on est vendredi aujourd'hui... ;-)
mais oui, une dépendance peut être optionnelle, je ne vois pas le problème.
Par exemple, sous kdesvn, par défaut il me fait le diff avec un outil kde "basique".
Si j'installe kompare, il va l'utiliser pour représenter les diffs.
Initialement kdesvn n'en avait pas besoin. Néanmoins, kdesvn permet de l'utiliser si celui-ci existe. Il y a bien une dépendance entre les deux, mais non obligatoire.
Maintenant, avec un système sans suggestions, si le packager ne veut pas de kompare (ce qui semble correct car non nécessaire) alors l'installation de kdesvn ne me permettra pas de voir mes diffs avec. Si le packager veut lui utiliser kompare, alors il me force à l'installer et peut-être je ne le voulais pas.
Il suffit alors que kdesvn viennent avec une dépendance optionnelle (je parlais bien de dépendance au sens require de rpm) et lorsque je vais l'installer il me dira que le soft marche sans kompare mais que si je veux il me propose de l'installer car kdesvn l'utilisera alors.
Faire ceci en dehors de rpm est illogique. Les dépendances sont dans les .spec et à mon avis, dépendances et suggestions doivent être au même niveau .
[^]Re: dommage
> Finalement je crois que je comprend pourquoi il y a un fork de rpm...
Je viens de regarder, les suggest ont été ajoutés au format rpm.
Mais rpm (de rpm.org) n'en fait rien.
[^]Re: dommage
> Et comme c'est une dépêche Mandriva, Mandriva ne l'utilise pas (puisque de toute manière ça n'existe pas).
Si si, ca existe, et c'est utilisé sur certains packages sur Mandriva.
$ rpm --help
[...]
--suggests list capabilities this package suggests
[^]Re: dommage
C'est un patch spécifique Mandriva.
Comme je l'ai dit ailleurs, les champs SUGGESTSNAME, etc on été ajouté au format rpm (donc c'est upstream).
[^]Re: dommage
> Fedora a des "dépendances molles", c'est traitée avec le fichier comps.xml. C'est dans ce fichier qu'on trouvera les décisions "politiques". Pas au plus bas niveau.
Les Suggests ne sont pas plus des décisions politiques que les Requires ...
> Ben parfois oui. Parfois il est fait pour plusieurs distributions.
Peu etre que tu n'es pas au courant, mais ce n'est pas par ce que la fonctionnalité est disponible qu'il est obligatoire de l'utiliser tout le temps. Tu peux très bien ne pas l'utiliser quand tu fais des packages destinés à plusieurs distributions, ou bien prevoir que ces Suggests seront ignorés sur certaines.
> Même apt n'utilise pas ça à ma connaissance. Ça existe depuis des plombes, et ce n'est presque pas utilisé. C'est dire comme c'est une faux bonne idée.
urpmi l'utilise.
[^]Re: dommage
> Les Suggests ne sont pas plus des décisions politiques que les Requires ...
Foutaise.
S'il manque un require, ça ne marche pas. L'évaluation de "ça ne marche pas" n'est pas un avis polique. C'est un constat technique.
> urpmi l'utilise.
Mais ce sont des infos qui viennent de rpm ou d'ailleurs ?
[^]Re: dommage
> S'il manque un require, ça ne marche pas. L'évaluation de "ça ne marche pas" n'est pas un avis polique. C'est un constat technique.
Même chose avec les suggest, si on les installe ça marche mieux, il y a plus de fonctionnalités puisque des composants non essentiels sont alors disponibles. C'est aussi un constat technique.
Par exemple: k3b fait usage de cdrecord/wodim, cdrdao et growisofs, mais il peut se passer de tous (on peut utiliser k3b pour faire de l'extraction de cd audio par exemple). Donc à ce niveau-là, utiliser le suggest pour indiquer que k3b permettra de faire plus de choses avec ces programmes est utile, et c'est bien au niveau du paquet que cette information est intéressante, parce qu'elle est vraie qu'elle que soit la distribution.
[^]Re: dommage
> Même chose avec les suggest, si on les installe ça marche mieux,
C'est ça. Firefox marche mieux avec Flash....
N'importe quoi.
[^]Re: dommage
Où as-tu vu un paquet firefox qui suggère flash?
Tu as inventé toi-même cet exemple et depuis tu passe ton temps à le sortir comme sois-disant preuve que le champ suggest est mauvais alors que nous somme plusieurs à te répéter que l'utilisation souhaitée d'un champ suggest n'est pas celle-là.
Pour te paraphraser, ce n'est pas parce que tu (avec ton exemple) viole l'usage prévu pour le champ suggest qu'il est mauvais.
[^]Re: dommage
Peut-être qu'il a peur d'une dérive ?
Si suggest est utilisé strictement pour indiquer des trucs de sécurité ou des trucs vraiment indispensable, pourquoi pas ? Mais qui va juger de ce qui est indispensable ou pas ? Par définition, suggest sous-entend un choix de l'auteur du paquet.
En même temps, suggest a bien sa place quand les paqueteurs ont acquis notre confiance, qu'on les connaît, et qu'on connaît l'esprit de la distro pour laquelle ils travaillent. Par exemple, j'ai tendance à faire confiance à Mandriva dans les paquets et l'équipement du bureau qu'ils me suggèrent d'installer... Et ça ne me dérangerait pas qu'ils me suggèrent le paquet Flash avec FF, moi.
Mais pour la dérive de suggest, on pourrait presque imaginer que la dérive ultime serait de faire de suggest une distribution à lui tout seul... Après tout, une distribution Linux, c'est l'installation du noyau, avec plein de suggest autour ! :-)
Je pense que suggest aura naturellement tendance à susciter la polémique et la dérive.
[^]Re: dommage
à mon avis, c'est un faux problème.
La confiance il faut déjà l'avoir, car bon suggest peut ptetre ajouter certaines choses (mais toujours optionelles) mais si le packageur est mauvais, il peut aussier ajouter de requires qu'on ne veut pas... et là c'est pire car on a pas le choix.
Donc ne pas vouloir suggest pour ceci, autant supprimer les dépendances...
Ce que je ne comprend pas c'est l'animosité que suggest provoque, si certains ne veulent pas de suggest ils n'ont qu'à pas installer ce qui est suggéré et leur distrib se comportera comme sans. Et ceux qui veulent profiter des améliorations le pouront.
[^]Re: dommage
On peut retourner le problème: pourquoi la solution des groupes ne convient pas ? C'est souple, ça fait la même chose, alors pourquoi vouloir imposer les suggestions ?
RPM se veut un outil bas-niveau dans l'esprit Unix, il fait une chose et il le fait bien. Après, c'est à l'outil de plus haut niveau de proposer des fonctionnalités plus avancés comme les suggestions.
Pourquoi s'amuser à complexifier RPM alors qu'il l'est suffisamment si ce n'est déjà trop ?
Hein, Fedora offre les groupes (géré par le fichier comps.xml), OpenSuSE offre également des "recommendations" et des "suggestions" via son One-Click Install. (http://en.opensuse.org/Build_Service/Tutorial)
Rien n'empêche Mandriva d'implémenter dans son urpmi ce mécanisme, rien ne les empêche de discuter avec les autres distributions à base de RPM d'implémenter un mécanisme commun sans forcément le foutre dans RPM.
[^]Re: dommage
oui et non...
rpm intègre déjà les requires. Les suggest ne sont que des dépendances optionnelles et sont justement au même niveau.
Franchement je ne vois pas pourquoi il y aurait une différence entre les 2.
Maintenant, oui, tout comme ce sont les front-end qui gèrent l'installation des dépendances, ces front-end peuvent traiter (ou non) les suggests à leurs niveaux.
Mais là ou ce serait vraiment intéressant c'est qu'il y aurait une (et une seule) façon d'indiquer les suggest pour tous les paquets rpms.
Le suggest fait partie du paquet et non de l'outil de gestion du paquet ou d'installation.
[^]Re: dommage
Et après, que fais tu des suggestions ? Même apt n'utilise pas ça à ma connaissance.
Hein ?
$ sudo apt-get install p7zip-fullLecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Paquets suggérés :
p7zip-rar
Les NOUVEAUX paquets suivants seront installés :
p7zip-full
0 mis à jour, 1 nouvellement installés, 0 à enlever et 1 non mis à jour.
Il est nécessaire de prendre 0o/1189ko dans les archives.
Après cette opération, 2931ko d'espace disque supplémentaires seront utilisés.
[^]Re: dommage
Autant pour moi.
Et pour synaptique ?
Es-ce que par exemple on peut avoir la liste des suggestions actuelles qui ne sont pas installées ?
[^]Re: dommage
Moi aussi je veux participer, donc je saute dans ce monstrueux troll !
La réponse courte : oui aptitude le permet
La réponse moyenne :
aptitude search '?not(?installed)?reverse-suggests(?installed)'
ou
aptitude search '!~i~R[suggest]~i'
La réponse plus longue :
http://algebraicthunk.net/~dburrows/projects/aptitude/doc/fr(...)
[^]Re: dommage
Oui, et pourquoi pas un firefox avec un require sur flash ? Faut il egalement retirer les requires de rpm ?
[^]Re: dommage
> Faut il egalement retirer les requires de rpm ?
Vous êtes con ou quoi ?
Un require c'est ce qui est nécessaire pour que ça marche. Ce n'est pas optionnel, ce n'est pas un conseil, ce n'est pas une suggestion, c'est nécesssaire.
Il y a peut-être des distributions qui ne respectent pas la signification de require, mais c'est leurs oignons. En tout cas Fedora respecte la signification de require. Si un require n'est pas nécessaire pour le bon fonctionnement du logiciel, ben fait un rapport de bug. Tu vas voir, le require sera supprimé.
Il y a même une chasse quasi permanente aux requires superflux.
[^]Re: dommage
Tu es con ou quoi, un suggest, c'est un paquet qui permet d'utiliser une fonctionalité supplémentaire. C'est optionnel, ce n'est pas un conseil, ce n'est pas une suggestion, ce n'est pas nécesssaire.
Il y a peut-être des distributions qui ne respectent pas la signification de suggest, mais c'est leurs oignons. En tout cas MaDistrib respecte la signification de suggest. Si un suggest ne représente pas une fonctionalité supplémentaire qui peut être ajoutée au logiciel, ben fait un rapport de bug. Tu vas voir, le suggest sera supprimé.
Il y a même une chasse quasi permanente aux suggest superflux.
[^]Re: dommage
> ce n'est pas nécesssaire.
Par définition, ce qui n'est pas nécessaire n'est pas requis. Donc ne mélangeons pas les Requires et les Suggests.
> Il y a même une chasse quasi permanente aux suggest superflux.
Suggest qui est un choix "politique".
[^]Re: dommage
> Il y a un truc qu'a deb et non rpm, c'est les suggestions.
rpm le fait aussi maintenant.
[^]Re: dommage
Pour avoir utilisé les deux :
- la rapidité de apt/dpkg à coté de yum et autres,
- la stabilité de la base de package debian qui se vautre quasiement jamais, alors qu'une base rpm explosé ça arrive.
Sinon ca joue pas énormément sur la qualité de la distro, ce qui fait la différence entre deux c'est surtout la qualité des packages, plutot que le système de package en lui même.
[^]Re: dommage
la rapidité de apt/dpkg à coté de yum et autres
C'est vrai que yum est lent, c'est le seul défaut que je reproche à fedora. Par contre, je pense qu'urpmi est assez rapide (même si je l'ai peu utilisé).
"La liberté ne peut être que toute la liberté ; un morceau de liberté n’est pas la liberté." -- Max Stirner
[^]Re: dommage
Pour avoir utilisé yum sur Fedora Core 6 je peux te dure que y a pas photo, yum se traînait comme un fou. Il paraît qu'ils ont bossé dessus... J'espère bien, parce que j'avais le temps d'aller faire une belote pour installer un package...
Ça fait 4 ans que j'utilise urpmi, depuis la Mandrake 9.1, j'ai jamais ressenti la même lourdeur, il a toujours été assez rapide.
[^]Re: dommage
> j'avais le temps d'aller faire une belote pour installer un package...
Faut pas pousser.
Quelques exemples :
J'ai des mises à jour en attente en attentes :
# time yum update
[...]
Transaction Summary
=============================================================================
Install 0 Package(s)
Update 20 Package(s)
Remove 0 Package(s)
Total download size: 29 M
[...]
real 0m53.804s
user 0m12.287s
sys 0m3.598s
Moins d'une minute pour 29 Mo (compressé).
Voici un autre petit test avec une installation mini (machine virtuelle kvm).
time yum install openoffice.org-writer
[...]
Transaction Summary
=============================================================================
Install 125 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 157 M
[...]
real 1m52.924s
user 0m23.623s
sys 0m19.857s
Moins de 2 minutes pour 157 Mo (compressé)
> j'avais le temps d'aller faire une belote pour installer un package...
Tu fais un belote en 1 minute ?
[^]Re: dommage
> - la stabilité de la base de package debian qui se vautre quasiement jamais, alors qu'une base rpm explosé ça arrive.
On est dans le myth. Un base rpm n'explose pas ou quasiment jamais.
Moi ça m'est jamais arrivé alors que j'utilise du rpm depuis maintenant plus de 10 ans !
Il y a des gens qui "explosent" leur base en utilisant les options "--nodeps" ou "--force". Mais ils l'ont cherché. Mais ce n'est pas vraiment une explosions de la base, car la base reste cohérente (c-à-d est l'image des conneries de l'utilisateur).
Par contre rpm est fragile face au coupure de courant (dpkg aussi). Dans ce cas la base rpm n'est pas corrompue (car rpm utilise un système transactionnel), mais il y a incohérence entre ce qui est installé et ce qui est indiqué dans la base et d'autres problèmes très emmerdant.
Rpm peut aussi être "emmerdé" en cas de manque d'espace disque. Notons que bien avant dpkg, rpm vérifie que l'espace disque est suffisant avant de faire l'installation. D'ailleurs je ne suis pas sûr que dpkg le fasse encore.
En passant, ce n'est pas car yum (ou équivalent) écrit un message d'erreur avec "erreur dépendance manquante" que la base rpm est "explosée". Et ce n'est pas car apt "cache" les dépendances manquantes que ça base n'est jamais "explosée".
[^]Re: dommage
> Et ce n'est pas car apt "cache" les dépendances manquantes que ça base n'est jamais "explosée".
des références à propos de ce mensonge honteux ?
[^]Re: dommage
> des références à propos de ce mensonge honteux ?
Je n'ai pas dit que c'était un mensonge (honteux).
Si tu veux la même chose avec yum, il y a le greffon yum-skip-broken.
C'est un choix qu'a fait apt, yum ne l'a pas fait (du moins par défaut).
[^]Re: dommage
Effectivement, c'est moi qui prétend que c'est un mensonge honteux parce que tu n'as toujours pas apporté la preuve de ce que tu dis. Alors je répète ma question plus clairement : où as-tu vu que «apt "cache" les dépendances manquantes» ?
[^]Re: dommage
Deuxième erreur, si pendant longtemps apt-get est resté sans véritable équivalent dans le monde RPM, c'est chose révolue avec yum (et je suppose actuellement urpmi)
Sinon, dpkg et RPM sont plus ou moins équivalent, chacun ayant des fonctionnalités avancés que l'autre n'a pas.
Urpmi ça date de 1999 qd même , c'est pas si jeune que ça ...
[^]Re: dommage
J'adore le "mais loin de moi l'idée de lancer le débat" juste après une remarque bien trollistique. C'est un peu comme les spammeurs qui écrivent "CECI N'EST PAS UN SPAM" dans leurs messages de spam.
[^]Re: dommage
Je me permets de te répondre, je n'ai jamais dit "RPM c'est de la merde".
J'ai uniquement donné un avis qui n'a pas la prétention d'avoir une valeur universelle.
Ne cherchons pas le diable partout !!
blog.collign.net
[^]Re: dommage
Trop gros, passera pas !
[^]Re: dommage
trop tard.
[^]Re: dommage
Pour rebondir sur ce troll avant de rajouter une info "pertinente".
La news ne parle pas d'urpmi.recover. Je suppose qu'ils ne communiquent pas encore dessus car pour eux ce n'est pas suffisamment stable mais perso j'ai testé et c'est très pratique.
Par exemple, hier j'ai voulu tester "conduit".
"urpmi conduit" et là il me dit qu'il doit installer 20 paquetages supplémentaires ! Avant je faisais un copier/coller fastidieux de la liste des paquetages pour faire un "urpme" si "conduit" ne m'intéresse pas.
Maintenant je fais "urpmi.recover -checkpoint" (Pour poser un point de retour et pour activer le système de retour arrière). Ensuite "urpmi conduit". Et si conduit ne m'intéresse pas "urpmi.recover -rollback 2008-04-09 23:30" (heure de l'install) et ça désinstalle tous les paquetages installés après cette date.
[^]Re: dommage
>Ensuite "urpmi conduit". Et si conduit ne m'intéresse pas "urpmi.recover -rollback
>2008-04-09 23:30" (heure de l'install) et ça désinstalle tous les paquetages installés
>après cette date.
Ca n'a quand même pas la souplesse d'un:
apt-get --purge autoremove
C'est dommage que urpmi ne soit pas capable de trouver tout seul ce qui n'a pas été implicitement installé par l'utilisateur.
Agogo
[^]Re: dommage
Cela n'a pas la souplesse mais cela n'a pas non plus le même rôle.
Si ça se trouve un équivalent au --purge existe sous rpm. Des experts sur le sujet ?
[^]Re: dommage
Pour supprimer toutes les bibliothèques inutilisées sur le système (nécessite quelques fois 2 passages) :
urpme `urpmi_rpm-find-leaves -g`
[^]Re: dommage
C'est pas la même chose qu'autoremove.
L'équivalent apt de ce que tu donnes, c'est
apt-get --purge remove `deborphan`autoremove propose d'enlever les paquets installés automatiquement par apt (genre libtrucmuch quand tu installes progfoo) qui n'est plus nécessaire (genre la mise à jour de progfoo ne dépend plus de libtrucmuch).[^]Re: dommage
Je connais pas bien apt-get mais urpme `urpmi_rpm-find-leaves -g` permet de supprimer toutes les bibliothèques inutilisées du systèmes (que tu appelles "installées automatiquement").
Par exemple sur mon poste, j'avais une lib qui trainait sans raison :
$ urpme `urpmi_rpm-find-leaves -g`
$ désinstallation de liblua5.0-5.0.3-4mdv2008.0.i586
$ désinstallation du paquetage liblua5.0-5.0.3-4mdv2008.0.i586
Voila, le ménage est fait.
[^]Re: dommage
Oui, j'ai bien compris, et ce n'est pas la même chose : si j'installe une bibliothèque à la main pour un programme que je compile, mais qui n'est pas utilisé par un autre package, urpme `urpmi_rpm-find-leaves -g` et la version debian utilisant deborphan vont m'enlever cette bibliothèque. Par contre, autoremove gardera cette bilbiothèque, car je l'ai installé moi-même, et c'est pas apt qui l'a installé à cause d'une dépendance.
[^]Re: dommage
Et si la lib se trouve installée par apt-get build-dep, est-ce qu'elle sera supprimée par autoremove?