Journal Passage de Debian a Mandriva 2007

Posté par  .
Étiquettes :
0
7
oct.
2006
Bonjour,

Je suis depuis un certains temps sous debian. Ayant testé le live cd 2007, j ai été bluffé par les avancés de la Mandriva (aussi bien pour ce qui est du Desktop (c'est sûre ça ne sert pas a grand chose, mais p#t#n que c'est beau !) que pour ce qui est du "léchage" (la finition quoi).

J aimerai connaître
1) vos retour si vous avez déjà fait le passage Debian -> Mandriva2007, ou si vous comptez les faire bientôt.

2) Un petit coup de main un peu plus technique: J aimerai savoir qu'elle est le pack a visé quand on viens de Debian et qu on ai habitué à ne faire que des apt-get update ; apt-get upgrade . De même, connaissant de nom urpmi (qui est si je ne me trompe l'équivalent d'apt-get), vers quoi pointe t-il par défaut: une source officiel (façon Debian) où ..rien?

D'avance Merci pour votre aide.
  • # Gestionnaire de packages

    Posté par  . Évalué à 3.

    Sous Mandriva, il existe deux gestionnaires de package :
    . en mode curses : urpmi
    . en mode graphique : smart

    Selon la version, le mieux est d'aller sur le site Easy Urpmi :
    http://easyurpmi.zarb.org/?language=fr

    @+

    Denis Szalkowski.
    http://dszalkowski.free.fr/dotclear/
    • [^] # Re: Gestionnaire de packages

      Posté par  . Évalué à 4.

      Sachant que smart s'utilise en console aussi.

      Perso je recommande à fond smart au détriment d'urpmi, je trouve smart mieux conçu que ce dernier.
      • [^] # Re: Gestionnaire de packages

        Posté par  (site web personnel) . Évalué à 3.

        moi qui utilise urpmi depuis un certain temps, pourrasi-tu me donner l'adresse d'une bonne doc sur les commandes de smart qui explique rapidement les commandes indispensables ?

        Sinon :
        apt-get update <-> urpmi.update -a (a condition que tu es utilisé le lien cité dessus pour configurer tes rouces)
        apt-get install lepaquet <-> urpmi lepaquet
        apt-get upgrade <-> urpmi --auto-select (--auto si tu veux pas de questions)
      • [^] # Re: Gestionnaire de packages

        Posté par  . Évalué à 3.

        Et surtout le mode shell...
        smart --shell
        et vive les
        ls *kde*
        install apache-*php*

        Que du bonheur !!
      • [^] # Re: Gestionnaire de packages

        Posté par  . Évalué à 4.

        smart ? c'est pas la techno qui a ete recupere suite a un achat...
        et que le mec qui maintenait celà a quitté mandriva quelques mois apres ?
        avant qu'il part c'etait prometeur... que urpmi etait pas aussi bien (si si je l'ai lu a l'epoque) et qu'en gros l'objectif etait peut être de migrer a smart?
        mais aujourd'hui...
        je me demande si smart est toujours maintenu, s'il evoluera...
        bref quel est la politique de mandriva a ce sujet ?
        • [^] # Re: Gestionnaire de packages

          Posté par  . Évalué à 6.

          > c'est pas la techno qui a ete recupere suite a un achat...

          C'est du libre, donc inutile d'aligner du pognon pour l'avoir.

          > c'etait prometeur...

          C'est toujours un excellent gestionnaire de paquet.

          > que urpmi etait pas aussi bien

          urpmi j'ai toujours trouvé ça naze. C'est compliqué, il y a 50 commandes, etc...
          OK, j'ai très très peu utilisé urpmi, mais c'est l'impression que ça donne quand on l'utilise (même peu) et quand on lit linuxfr.

          > je me demande si smart est toujours maintenu

          Oui : http://labix.org/smart/
          Dernière version sortie le 15/06/2006 : http://lists.labix.org/pipermail/smart-labix.org/2006-June/0(...)

          > bref quel est la politique de mandriva a ce sujet ?

          Je ne parlerai pas au nom de mandriva. Mais chez Fedora la question d'utiliser Smart a été posé car Smart est un très bon gestionnaire de paquet "dans son genre". Mais Smart pose plusieur problème à Fedora. Sa politique de résolutions des dépendances ne plait pas à Fedora (Fedora a de bonnes raisons de le penser). En effet, smart peut downgrader un paquet pour satisfaire des dépendances. Au moins pour des raisons de sécurité, Fedora se le refuse.
          L'autre problème, et il est lié au précédent, est que smart ne passe pas rpm-lib pour voir si les dépendances sont satisfaites.
          Smart ne supporte pas les groups de Fedora (fichier comps.xml ; à ne pas confondre avec les groupes de rpm).
          Smart ne permet pas de mixer i386 et x86_64.

          En conclusion, si on est d'accord avec le choix pour la résolution des dépendance fait par Smart, Smart est un excellent gestionnaire de paquet (et 50 fois plus simple que urpmi) et il mérite d'être plus populaire.
          Avis perso.
          • [^] # Re: Gestionnaire de packages

            Posté par  . Évalué à 2.


            > c'est pas la techno qui a ete recupere suite a un achat...
            C'est du libre, donc inutile d'aligner du pognon pour l'avoir.


            J'ai pas dis le contraire, le "suite" ca veux dire "apres que".. non pas "grace a", parcequ'effectivement mandriva s'est interressé a smart apres que mandriva ai acheté une boite (j'ai oublié le nom, fleme de chercher) ou bossait d'ailleur le dev de smart.

            sinon, merci pour ton avis, tres interressant.
            • [^] # Re: Gestionnaire de packages

              Posté par  . Évalué à 1.

              > mandriva ai acheté une boite (j'ai oublié le nom

              Conectiva. Egalement créateur de apt4rpm.
            • [^] # Re: Gestionnaire de packages

              Posté par  . Évalué à 1.

              Indice : avant mandriva s'appellait mandrake...
              • [^] # Re: Gestionnaire de packages

                Posté par  . Évalué à 2.

                ouais ok conectiva, mais comme je sais que mandriva a acheté plusieurs societes (au moins deux, peut être même trois recement j'ai du voir ça sur un site de news)...

                Bref, j'avais clairement pas envie de chercher, mais tout le monde avais compris.
                • [^] # Re: Gestionnaire de packages

                  Posté par  . Évalué à 1.

                  En même temps, la 2e société en question (Lindows je crois), c'etait 1 développeur. :)

                  Par contre, Connectiva était le leader en Amérique du Sud.
    • [^] # Re: Gestionnaire de packages

      Posté par  . Évalué à 7.

      j'aurai plutot dis urpmi pour le mode curses et rpmdrake pour le mode graphique, surtout qu'il a subit un bon lifting pour la 2007
  • # mais p#t#n que c'est beau !

    Posté par  . Évalué à 2.

    On peut avoir des screenshots ? :)
  • # Cas réel

    Posté par  (site web personnel) . Évalué à 8.

    1) vos retour si vous avez déjà fait le passage Debian -> Mandriva2007, ou si vous comptez les faire bientôt.
    J'avais un dédié debian, mais maintenant j'ai plus alors c'est une mandriva 2007 qui le remplace avantageusement...

    Enfin ce que j'apprécie surtout c'est un rangement CLAIR des fichiers (norme LSB machin chose), une homogénéité dans le placement des fichiers et une configuration qui marche out-of-box avec les exemples de config de base commentés.

    Genre shorewall le /etc/shorewall/ est remplis avec les "templates" pour tous les fichiers de conf (pas le cas chez debian).

    Bref sans oublie les outils de configuration de serveur : drakwizard(s) qui te mache la config de base et t'installe les dépendances qui vont bien...

    A noter que certains modules optionnels peuvent être marqué comme dépendance (par exemple le module ldap de proftpd), c'est du au limite du format rpm et du fait que la mise a jour 2006 (proftpd monolithique) => 2007 (proftpd modulaire) dois garder proftpd fonctionnel, alors quelques paquets peuvent être installés en plus...
    (tu peux toujours les virer a coup de : rpm -e --nodeps paquet_optionnel)

    2) Un petit coup de main un peu plus technique: J aimerai savoir qu'elle est le pack a visé quand on viens de Debian et qu on ai habitué à ne faire que des apt-get update ; apt-get upgrade . De même, connaissant de nom urpmi (qui est si je ne me trompe l'équivalent d'apt-get), vers quoi pointe t-il par défaut: une source officiel (façon Debian) où ..rien?

    Pour faire simple :
    http://easyurpmi.zarb.org/

    Tu vire les sources du cd (ça sert a rien a part se faire ch**r avec une galette a insérer si tu a le net rapide) :
    # urpmi.removemedia -a

    Tu ajoute les source de easyurpmi :
    # urpmi.addmedia main ftp://ftp.proxad.net/............../media/main/release with media_info/hdlist.cz
    # urpmi.addmedia contrib ftp://ftp.proxad.net/............../media/contrib/release with media_info/hdlist.cz
    # urpmi.addmedia main_updates ftp://ftp.proxad.net/............../media/main/update(s?) with media_info/hdlist.cz
    (....)
    #heu je suis pas sur du chemin du dernier, bref grosso modo tu met les diverses sources disponibles :
    main_release, main_testing(les futures updates), main_update, contrib_release, contrib_update, contrib_testing, plf-free, plf-nonfree

    Une fois ceci régulièrement tu met a jour les sources :
    # urpmi.update -a

    Tu met tout a jour :
    # urpmi --auto-select
    Les options :
    --keep pour garder les paquets installé et ne rien enlever (quand il y a un paquet manquant ou pas encore dispo sur le ftp par exemple)
    --allow-force pour dire a urpmi de pas te casser les pieds avec des dépendances inutiles, il te demandera de valider manuellement si il dois forcer les choses (utile pour installer un paquet fait a la main qui demande une dépendance que tu sais fantaisiste)
    --excludemedia xxx pour exclure le media xxx
    --media xxx pour ne s'occuper que du media en question

    Recherche :
    $ urpmf /usr/lib/libssl.so
    libopenssl0.9.8:/usr/lib/libssl.so.0.9.8
    libopenssl0.9.8-devel:/usr/lib/libssl.so

    $ urpmq -i mplayer
    Name : mplayer
    Version : 1.0
    Release : 1.pre8.13plf2007.0
    Group : Video
    Size : 17869693 Architecture: i586
    Source RPM : mplayer-1.0-1.pre8.13plf2007.0.src.rpm Build Host: virgo
    Packager : G½tz Waschk <goetz@zarb.org>
    URL : http://www.mplayerhq.hu
    Summary : Movie player for linux
    Description :
    MPlayer is a movie player for LINUX
    (snip)

    $ urpmq -l unpaquet
    chemin1/fichier1
    chemin2/fichier2

    Après le reste pas besoin, sauf ptet :
    # urpme basesystem
    La désinstallation du paquetage basesystem-2007.0-2mdv2007.0.i586 rendra votre système instable
    Rien à désinstaller
    ;)

    Vala, après regarde les options disponibles dans le --help des commandes en question...
    • [^] # Re: Cas réel

      Posté par  (site web personnel) . Évalué à 2.

      Tu vire les sources du cd (ça sert a rien a part se faire ch**r avec une
      galette a insérer si tu a le net rapide) :

      Ah, perso j'ai préféré cocher la case demandant la copie du contenu du DVD afin de ne plus avoir à l'insérer tout en ayant les packages (zippés) dispos. Faut juste avoir qq Go de libres sur son disque dur.

      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

  • # urmi

    Posté par  (Mastodon) . Évalué à 4.

    petit rappel de ce que urpmi est capable de faire :
    rechercher selon divers filtres / installer-desintaller ...
    filtres avancés (exclusion de certains noms ou parties de noms par exemple)
    gestion avancée des dépendances
    gestion des signatures
    gestion des débits, splitter en transactions, splitter par poids,
    garder/enlever du cache (et gestion avancé de celui-ci)
    passer par un proxy, utiliser ssh curl et wget, synchronisation...
    gestion de liste d' exclusion précise
    reconstructions
    gestion des architectures
    ne pas exécuter les scriptlets
    installation en parallèle sur plusieurs (dizaine(s) ...) de postes.
    gestion d' un parc d' ordinateurs
    gérer complètement les chroot depuis l' environnement courant.
    utiliser un environnement différent
    et encore quelques autres!
    Tout avec les options de la commande rpm originelle.

    Pour ceux qui seraient intéressés par plus d' infos, ils peuvent consulter ces pages du projet EDOS : http://www.edos-project.org/xwiki/bin/Main/AnalysisOfSomePac(...)

    quant à easyurpmi, il ne sert plus que pour le PLF
    la configuration des miroirs main & updates se fait toute seule, en 2 clicks dans drakrpm-edit-media "ajouter une source"

    Pour la question
    J aimerai savoir qu'elle est le pack a visé quand on viens de Debian
    les outils sont similaires sur tout les packs. De plus chaque packs permet d' accéder aux mêmes miroirs online (aux mêmes paquets, donc), enfin chaque look de packs peut être modifier à sa guise vers un autre 'tout prêt'.

    note additionnelle : tu peux aussi utiliser apt sur mandriva de manière transparente, avec apt-get-rpm. Mais urpmi roxe bien ;)
    • [^] # Re: urmi

      Posté par  . Évalué à 5.

      Bof, Emacs fait deja tout ca et bien plus.
    • [^] # Re: urmi

      Posté par  (Mastodon) . Évalué à 2.

      ps éventuellement utile : le site edos est obsolète aujourdhui, mais la lecture de ce site reste néanmoins une source intéressante.

      pour ajouter plf en plus des miroirs main et contrib, voici la commande (syntheis hdlist est ici utilisé : c est la liste "petite & légère", la liste avec toutes les infos est simplement hdlist.cz mais synthesis est très bien ;) ) (attention à la coupure du lien par le wiki ici !)

      urpmi.addmedia plf-free ftp://ftp.free.fr/pub/Distributions_Linux/plf/mandriva/free/(...) with synthesis.hdlist.cz
      urpmi.addmedia plf-non-free ftp://ftp.free.fr/pub/Distributions_Linux/plf/mandriva/non-f(...) with synthesis.hdlist.cz
    • [^] # Re: urmi

      Posté par  . Évalué à 0.

      Pour le fun, comparaison avec Yum/rpm.

      > rechercher selon divers filtres / installer-desintaller

      Yum search. Combiné avec --enablerepo et --disablerepo, ça le fait.
      Pour un recherche fine des paquets installé, rpm avec les options --queryformat --whatrequires --whatprovides est ce qu'il y a de mieux.

      Avec Yum, il y a aussi le programme repoquery. Il n'interroge pas la base rpm locale (/var/lib/rpm). On retourve toute la puissance de "rpm --queryformat" + --whatrequires --whatobsoletes --whatconflicts --resolve.

      > filtres avancés (exclusion de certains noms ou parties de noms par exemple)

      Yum --exclude. C'est aussi configurable dans /etc/yum.conf ou via des fichiers dans /etc/yum.repo.d/
      Il y a aussi les plugin yum-protectbase, plugin yum-versionlock, yum-allowdowngrade, yum-kernel-module et yum-fedorakmod.

      > gestion avancée des dépendances

      Heureusement. Idem pour tout le monde.

      > gestion des signatures

      C'est-à-dire ?
      Yum vérifie si le paquet est signé, il peut aussi importer une signature (via ftp, http, etc).

      > gestion des débits, splitter en transactions, splitter par poids,

      Yum n'a pas.
      Il y a yum-fastestmirror.

      > garder/enlever du cache (et gestion avancé de celui-ci)

      Yum n'a pas. Mais le cache est si petit (ici 100 Mo pour 5700 paquets info de liste de fichier comprise (alors que c'est peut utilisé)).

      > passer par un proxy, utiliser ssh curl et wget

      Yum a.

      > synchronisation...

      reposync.

      > gestion de liste d' exclusion précise

      ???
      Consédirons que Yum n'a pas.

      > reconstructions

      Yum n'a pas.
      Mais c'est tellement con à faire avec rpm : rpm --rebuild [url]
      Il y a aussi yum-builddep pour installé les *-devel nécessaires.

      > gestion des architectures

      Yum a. +gestion biarch.

      > ne pas exécuter les scriptlets

      Il y a le plugin yum-tsflags. Mais franchement, vu que yum/urpmi peut installé plusieurs paquets, c'est une mauvaise idée. Rpm le fait "--noscript --notrigger".

      > installation en parallèle sur plusieurs (dizaine(s) ...) de postes.

      Un serveur urpmi ?
      C'est assez con à faire avec yum-updatesd (indique s'il y a des mises à jours via syslog, mail et dbus).
      Peut aussi mettre à jours automatique et downloader.
      Exemple d'un fichier de configuration :
      # automatically install updates
      do_update = no
      # automatically download updates
      do_download = no
      # automatically download deps of updates
      do_download_deps = no


      Après pour l'installation automatique d'un nouveau paquet, il suffit d'installé un paquet "meta", voire un nouveau fedora-release avec un epoc supérieur à celui fournit par défaut pour être tranquille. Ainsi toute les bécanes qui point sur le dépôt on le paquet. S'il faut ajouter un programme, on ajoute un Require au paquet. S'il faut virer un programme, on ajoute un tag "obsolete".
      Pas compliqué à faire pour 1, 10 ou 200 000 machines.

      > gestion d' un parc d' ordinateurs

      Ça m'étonnerait que urpmi fasse ça.

      > gérer complètement les chroot depuis l' environnement courant.

      ???
      yum --installroot. NB, ça aussi évidement fournit par rpm.

      > utiliser un environnement différent

      ???
      Ben avec setarch, -c [config file] et --installroot, je ne vois pas ce qu'on peut vouloir de plus.
      Sous Fedora yum est utilisé pour installer des machines virtuelles (Xen).

      > et encore quelques autres!

      Idem pour yum. Tiens, il y a repoview :
      http://fr2.rpmfind.net/linux/fedora/core/5/x86_64/os/repodat(...)
      Et un flux rss :
      http://fr2.rpmfind.net/linux/fedora/extras/5/i386/repodata/l(...)
      Sympathique, non ?


      Je ne veux pas dénigrer urpmi.
      L'avantage de yum, c'est qu'il est simple. S'il faut faire des trucs compliqués, il y a d'autres programmes.
      Pour Yum et un utilisateur classique, il faut une page man. Pour urpmi, il faut un site dédié à la maitrise de urpmi.
      Pour ton info, compares aussi avec smart.
      • [^] # Re: gestion de parc d'ordis

        Posté par  . Évalué à 1.

        le gestionnaire de parc est fait par urpmi, et il y a même un gui pour ça (dans la 2006 ça s'appelait drakpark et faisait appel à urpmi --parallel ...)

        et il y a les drakwizzards qui permettent de gérer pas mal de fonctionnalités de pas mal d'outils accessibles en ligne de commande...
  • # Un petit tuto

    Posté par  (site web personnel) . Évalué à 2.

    http://linux-wizard.net/howto.php?section=5&key=gestion_(...)
    Urpmi est en fin de page, mai tous l'article est une référence pour moi...
  • # Traître !!

    Posté par  . Évalué à 3.

    non, tu n'es pas un traître en fait, tu as raison d'essayer autre chose.
    Pour ma part je reste fidèle à Debian mais je teste également SuSE qui n'est pas mal non plus.
    Au niveau des standardisations des fichiers de configuration, est-ce que LSB va dans ce sens également ?
    Sur http://www.freestandards.org/en/Products je vois suse (et opensuse aussi ?), red had, xandros, asianux (et pas mandriva ?), mais je ne crois pas que les fichiers de conf. soient unifiés ce qui est un peu dommage.

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.