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.
Journal Passage de Debian a Mandriva 2007
7
oct.
2006
# Gestionnaire de packages
Posté par Denis Szalkowski . Évalué à 3.
. 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 alexissoft . Évalué à 4.
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 djibb (site web personnel) . Évalué à 3.
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 Spyhawk . Évalué à 4.
Il y a aussi une FAQ en français.
[^] # Re: Gestionnaire de packages
Posté par djibb (site web personnel) . Évalué à 2.
[^] # Re: Gestionnaire de packages
Posté par Geo Vah . Évalué à 3.
smart --shell
et vive les
ls *kde*
install apache-*php*
Que du bonheur !!
[^] # Re: Gestionnaire de packages
Posté par fabien . Évalué à 4.
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 clearstream . Évalué à 6.
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 fabien . Évalué à 2.
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 clearstream . Évalué à 1.
Conectiva. Egalement créateur de apt4rpm.
[^] # Re: Gestionnaire de packages
Posté par Anonyme . Évalué à 1.
[^] # Re: Gestionnaire de packages
Posté par fabien . Évalué à 2.
Bref, j'avais clairement pas envie de chercher, mais tout le monde avais compris.
[^] # Re: Gestionnaire de packages
Posté par Spyhawk . Évalué à 1.
Par contre, Connectiva était le leader en Amérique du Sud.
[^] # Re: Gestionnaire de packages
Posté par lezardbreton . Évalué à 2.
[^] # Re: Gestionnaire de packages
Posté par neoclust . Évalué à 7.
# mais p#t#n que c'est beau !
Posté par andeus . Évalué à 2.
[^] # Re: mais p#t#n que c'est beau !
Posté par François Garnier (site web personnel) . Évalué à 3.
[^] # Re: mais p#t#n que c'est beau !
Posté par Joc M . Évalué à 2.
# Cas réel
Posté par Raphaël G. (site web personnel) . Évalué à 8.
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 lolop (site web personnel) . Évalué à 2.
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 bubar🦥 (Mastodon) . Évalué à 4.
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
[^] # Re: urmi
Posté par pasBill pasGates . Évalué à 5.
[^] # Re: urmi
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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 clearstream . Évalué à 0.
> 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 :
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 glyj . Évalué à 1.
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 liberforce (site web personnel) . Évalué à 2.
Urpmi est en fin de page, mai tous l'article est une référence pour moi...
# Traître !!
Posté par B16F4RV4RD1N . Évalué à 3.
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.