> Ce qui sous Gentoo correspond par définition à la notion de paquet virtuel (genre si on a besoin d'un driver alsa ("virtual/alsa"), on peut se satisfaire soit d'un kernel 2.5/6, soit du driver pour les 2.4).
Pour en revenir au librairies, si le binaire définit les librairies qu'il a besoin, il vaut mieux avoir un système automatique pour détecter les dépendances avec les librairies que de faire ça à la main. Mais puisque ça te plait, tu peux faire des paquets avec :
requires|provide : "virtual/alsa".
Mais "virtual/alsa" ne dit pas que le paquet ne peut marché d'avec un Linux > 2.4.17 ou < 2.4.21 car une api a changé ou qu'il faut que les fontionnalité real-time soient disponibles ou plus simplement que le module soundcore soit présent. Seulement "virtual/alsa" est de la gestion de dépendance à la petite semaine.
Puis pour les services rendus par plusieurs paquets il y a aussi des facilités virtuels.
exemple :
$ yum provides ftpserver
Available package: vsftpd proftpd wu-ftpd provides ftpserver
> Enfin si, je sais plus si rpm le fait, ou le faisais à une époque lointaine en tout cas, ou si c'est urpmi qui le rajoute
C'est rpm qui le fait et non urpmi/etc. Par rapport à urpmi/apt/yum , rpm est un outil bas niveau et ne fait pas de recherche de paquet pour respecter les dépendances (c'est le boulot d'apt/urpmi/...). Par contre si les dépendances ne sont pas respectées, l'installation/mise_à_jour est refusée par rpm. C'est à urpmi/apt/yum de rechercher les bons paquets suivant des critères retourné par rpm et de les proposer à rpm qui fait tous les contrôles et l'installation (ce que ne fait pas urpmi/apt/...). Ainsi un "yum remove gtk+" fera un "rpm -e --test gtk+" pour connaitre les paquets qu'il faut desinstaller pour supprimer gtk+. (question : il se passe quoi si tu demandes la suppression de gtk+ sur une gentoo ?)
Il faut noter qu'urpmi ou yum sont des petits projets par rapport à rpm. rpm est 20 à 30 fois plus gros que yum ou urpmi qui utilise rpm alors que les gens n'ont d'yeux que pour urpmi/yum/... C'est les facilités de rpm qui permettent ça. Yum ou urpmi, des équivants d'apt mais dédiés rpm, font dans les 5 000 lignes de code seulement.
> Je sais pas dans le monde .rpm, mais dans le monde .deb c'était plutôt ce qu'on appelait des meta-paquets.
Dans la pratique, c'est peu utilisé avec rpm :-). Mais c'est présent (voir plus haut).
Puis que "meta-paquet" ça te plais, il te suffis de faire un paquet vide avec uniquement des "require: ..." et t'as un "meta-paquet".
> Franchement, je préfère de loin l'abstraction des virtuals (tu fait comment avec un nom de fichier pour dire: un codec divx ?)
Si c'est un librairie, tu ne fais rien.
Si la detection automatique n'est pas satisfesante (par exemple plusieurs nom de librairie pour la même fonctionnalité) tu fais une dépendance "virtuel"
"require : codec_divx >= 4".
Un paquet qui fourni cette fonctionnalité a par exemple :
"provide : codec_divx = 4.1".
Tous les paquets rpm on la dépendance vituelle : "provide : %{name} = %{version}"
Tu peux en ajouter autant que tu veux.
Je vois pas pourquoi tu insiste sur le "virtuel".
rpm detecte automatiquement s'il faut libc.so.6(GLIBC_2.3) ou libc.so.6(GLIBC_2.1.3) . Ça n'a rien de virtuel et ça évite bien des conneries. Maintenir en "virtuel" les dépendances avec la librairie C est un véritable enfer. Ma librairie C fournit la comptabilité avec 15 (!) versions (2.0 à 2.3.3). Certains paquets ont besoin de la 2.1.3 d'autres de la 2.3 etc... rpm contrôle tout automatiquement. J'ai vraiment pas envis de renseigner ces informations à main.
> Bah manquerai plus que l'install d'un paquet t'écrase ta config existante? Sérieux, c'est encore vraiment la base.
Tu ne comprends pas. Si un fichier de configuration est déréférences dans la base rpm le fichier est renommé toto.rpmsave (s'il est modifié par rapport à la version de référence). Si un fichier de conf peut-être écrasé il est renommé toto.rpmsave et il y a des options pour ne pas toucher au fichier de config (les nouveaux sont nommés toto.newrpm). Il y a aucun problème avec ça.
Par contre, lorsque rpm ne supportait la gestion des configurations, passer de ppp à ppp_ng (c'est un paquet différent) alors que c'est le même format de fichiers de configuration, aurait créé des .rpmsave (ou .newrpm). Maintenant ce n'est plus le cas.
> C'est merveilleux tellement c'est aller loin contre le bon sens et la simplicité.
Recompilé c'est tellement plus "simple"...
> Cool, ça vous fait un USE flag. Aller, encore un petit effort, c'est presque ça.
Tu ne comprends pas. J'ai rien contre USE qui va "paramétrer" la compilation des paquets et c'est un dispositif très utile. Je parle de la gestion des dépendances. De ce que je comprends, USE n'a rien à voir avec la gestion des dépendances.
Pour rpm on pourrait définir un convention des facilités à utiliser pour compiler un paquet avec "--with qt" ou "--without qt". C'est courament fait.
Exemple :
$ rpm -i proftpd
[...]
Available rpmbuild rebuild options :
--with : ldap mysql postgres tls
$ rpm -i alsa
Available rpmbuild rebuild options :
--without : isapnp sequencer oss
You may also recompile for given cards only by calling rpmbuild with :
--define "cards card1,card2,card3"
(the default is "cards all")
You may also recompile for a given kernel version and arch with :
--define "kernel <uname -r output>"
(for example "kernel 2.4.20-9")
--target
Mais même avec un système pour "châpeauter" la contruction des rpm, ce n'est pas un système de gestion de dépendance. A moins que USE puisse te dire :
- "compilation/installation de KDE refusé car qt n'est pas disponible"
au-lieu de planter au milieu de la compilation.
> Ça va en faire des versions spécifiques à compiler pour RedHat
Je crois que tu n'as pas bien compris le système. D'une certain manière on peut dire que c'est pour avoir des espaces de paquet séparés et éviter les conflits. Imaginons que ximian utilisé un Epoch=12 par exemple, le paquet nommé toto chez redhat ne va pas interférer avec le paquet toto de de xiniam et quelque soit la version des paquets. Par exemple tu ne peux pas mettre à jour libtoto-1.0-1 de ximian par un libtoto-1.0-2 de redhat si le paquet toto réclame un 12:libtoto . Le "Epoch" est prioritaire. L'objectif n'est pas de compiler des 10 façons différentes le même paquet. Il y a d'autres mécanismes pour ça ("--define", "--with", "--without").
> > Rpm gère les paquets absolètes.
> Pur narcissisme.
Exemple concret. Apache fournit maintenant mod_dav alors qu'avant c'était un paquet séparé. Dans le paquet il y a :
Obsoletes: mod_dav
Le nouveau paquet apache est autorisé à supprimer mod_dav puisqu'il le fourni. Sinon rpm indique un conflit (il ne va pas desinstaller un paquet sans "authorisation") et il faut désinstaller mod_dav avant de mettre le nouveau apache.
C'est aussi utilisé pour changer de version de distribution. Si la distribution passe de wu-ftpd à proftpd, il y aura dans proftpd :
Obsoletes: wu-ftpd
wu-ftpd sera supprimé si proftpd est installé. Ce qui est normal si le distributeur ne veut plus supporter wu-ftpd.
C'est aussi grace à ça que les gens passent de Mandrake 9.0 à 9.1 ou redhat 8.0 à 9 sans tout réinstaller.
C'est toujours du "Pur narcissisme" pour toi ?
> Moi je suis sûr grâce à ton post que bientôt rpm aura rattrapé son retard sur apt.
C'est d'une "naïveté"... apt existe pour rpm. rpm n'est pas l'équivalent d'apt !
up2date ou urpmi ou yum sont des équivalents d'apt. L'équivalent de rpm dans le monde apt est dpkg.
> vrais paquets virtuels
Fait.
> héritage entre specs
???
> gestion explicite des masques de paquets
???
Tu parles peut-être encore de compilation alors que je parle de gestion de dépendance pour un système rpm qui n'est pas orienté source.
> mélange aisé de 3 niveaux de stabilité des paquets
Fait.
> système de merge des fichiers de conf
Fait, c'est les triggers du paquet qui le font. Du moins si le paquet est développé pour le faire.
> Mais il n'approche qu'à peine (et c'est bien normal, mauvais choix, mauvais résultats) la souplesse que peut offrir un système basé sur les sources ... blabla source compilation etc
rpm n'est pas fait pour faire une distribution orienté source. Comparer rpm à gentoo sur ce point n'a pas de sens.
Par contre il est possible de faire une surcouche à rpm pour faire une distribution orienté source. Les binaires stokent le nom du paquet src.rpm qui stockent ce qui est nécessaire pour la compilation qui est elle-même paramétrable via --define --with --without. Une sourcouche pour "piloter" tout ça est tout a fait envisagable.
Mais avec ça on reste loin de la possilité de faire ça depuis les sources :
$ yum install_build_from_source provides libgnomeui-2.so.0
ou
$ yum install_build_from_source provides /usr/X11R6/bin/xscreensaver-demo
Or ça marche avec les binaires et avec résolution des dépendances. A moins de tout mettre en dure (pas de detections automatiques) ça ne peut pas marcher avec les sources. Tout mettre en dure n'est pas une bonne solution si on ne veut pas système bordélique.
> Alors que franchement, sur une distrib à la redhat, c'est quoi la proportion d'utilisateurs qui ont un jour fait leur propre srpm ?
T'as prouvé ton ignorance complète sur rpm.
Si tu veux une distribution orienté source, reste sous Gentoo. Personne n'a dit que les distributions actuelles basées sur rpm étaient des distributions orientées source.
Si les .rpm et .deb sont sur la place depuis un moment, ce n'est pas un hazard et surement pas à cause de "mauvais choix" comme tu dis.
Mais quels "mauvais choix" ? Tu peux t'expliquer ?
Le "mauvais choix" de n'avoir pas mis la priorité sur les distribution orienté source ?
Réjouis toi alors. Ça garanti un succès fulgurant de gentoo. Mais pour quand ? Car la déferlante on ne la voit pas venir actuellement.
[^] # Re: Test de la Gentoo 1.4
Posté par Austin . En réponse à la dépêche Test de la Gentoo 1.4. Évalué à 0.
Pour en revenir au librairies, si le binaire définit les librairies qu'il a besoin, il vaut mieux avoir un système automatique pour détecter les dépendances avec les librairies que de faire ça à la main. Mais puisque ça te plait, tu peux faire des paquets avec :
requires|provide : "virtual/alsa".
Mais "virtual/alsa" ne dit pas que le paquet ne peut marché d'avec un Linux > 2.4.17 ou < 2.4.21 car une api a changé ou qu'il faut que les fontionnalité real-time soient disponibles ou plus simplement que le module soundcore soit présent. Seulement "virtual/alsa" est de la gestion de dépendance à la petite semaine.
Puis pour les services rendus par plusieurs paquets il y a aussi des facilités virtuels.
exemple :
$ yum provides ftpserver
Available package: vsftpd proftpd wu-ftpd provides ftpserver
> Enfin si, je sais plus si rpm le fait, ou le faisais à une époque lointaine en tout cas, ou si c'est urpmi qui le rajoute
C'est rpm qui le fait et non urpmi/etc. Par rapport à urpmi/apt/yum , rpm est un outil bas niveau et ne fait pas de recherche de paquet pour respecter les dépendances (c'est le boulot d'apt/urpmi/...). Par contre si les dépendances ne sont pas respectées, l'installation/mise_à_jour est refusée par rpm. C'est à urpmi/apt/yum de rechercher les bons paquets suivant des critères retourné par rpm et de les proposer à rpm qui fait tous les contrôles et l'installation (ce que ne fait pas urpmi/apt/...). Ainsi un "yum remove gtk+" fera un "rpm -e --test gtk+" pour connaitre les paquets qu'il faut desinstaller pour supprimer gtk+. (question : il se passe quoi si tu demandes la suppression de gtk+ sur une gentoo ?)
Il faut noter qu'urpmi ou yum sont des petits projets par rapport à rpm. rpm est 20 à 30 fois plus gros que yum ou urpmi qui utilise rpm alors que les gens n'ont d'yeux que pour urpmi/yum/... C'est les facilités de rpm qui permettent ça. Yum ou urpmi, des équivants d'apt mais dédiés rpm, font dans les 5 000 lignes de code seulement.
> Je sais pas dans le monde .rpm, mais dans le monde .deb c'était plutôt ce qu'on appelait des meta-paquets.
Dans la pratique, c'est peu utilisé avec rpm :-). Mais c'est présent (voir plus haut).
Puis que "meta-paquet" ça te plais, il te suffis de faire un paquet vide avec uniquement des "require: ..." et t'as un "meta-paquet".
> Franchement, je préfère de loin l'abstraction des virtuals (tu fait comment avec un nom de fichier pour dire: un codec divx ?)
Si c'est un librairie, tu ne fais rien.
Si la detection automatique n'est pas satisfesante (par exemple plusieurs nom de librairie pour la même fonctionnalité) tu fais une dépendance "virtuel"
"require : codec_divx >= 4".
Un paquet qui fourni cette fonctionnalité a par exemple :
"provide : codec_divx = 4.1".
Tous les paquets rpm on la dépendance vituelle : "provide : %{name} = %{version}"
Tu peux en ajouter autant que tu veux.
Je vois pas pourquoi tu insiste sur le "virtuel".
rpm detecte automatiquement s'il faut libc.so.6(GLIBC_2.3) ou libc.so.6(GLIBC_2.1.3) . Ça n'a rien de virtuel et ça évite bien des conneries. Maintenir en "virtuel" les dépendances avec la librairie C est un véritable enfer. Ma librairie C fournit la comptabilité avec 15 (!) versions (2.0 à 2.3.3). Certains paquets ont besoin de la 2.1.3 d'autres de la 2.3 etc... rpm contrôle tout automatiquement. J'ai vraiment pas envis de renseigner ces informations à main.
> Bah manquerai plus que l'install d'un paquet t'écrase ta config existante? Sérieux, c'est encore vraiment la base.
Tu ne comprends pas. Si un fichier de configuration est déréférences dans la base rpm le fichier est renommé toto.rpmsave (s'il est modifié par rapport à la version de référence). Si un fichier de conf peut-être écrasé il est renommé toto.rpmsave et il y a des options pour ne pas toucher au fichier de config (les nouveaux sont nommés toto.newrpm). Il y a aucun problème avec ça.
Par contre, lorsque rpm ne supportait la gestion des configurations, passer de ppp à ppp_ng (c'est un paquet différent) alors que c'est le même format de fichiers de configuration, aurait créé des .rpmsave (ou .newrpm). Maintenant ce n'est plus le cas.
> C'est merveilleux tellement c'est aller loin contre le bon sens et la simplicité.
Recompilé c'est tellement plus "simple"...
> Cool, ça vous fait un USE flag. Aller, encore un petit effort, c'est presque ça.
Tu ne comprends pas. J'ai rien contre USE qui va "paramétrer" la compilation des paquets et c'est un dispositif très utile. Je parle de la gestion des dépendances. De ce que je comprends, USE n'a rien à voir avec la gestion des dépendances.
Pour rpm on pourrait définir un convention des facilités à utiliser pour compiler un paquet avec "--with qt" ou "--without qt". C'est courament fait.
Exemple :
$ rpm -i proftpd
[...]
Available rpmbuild rebuild options :
--with : ldap mysql postgres tls
$ rpm -i alsa
Available rpmbuild rebuild options :
--without : isapnp sequencer oss
You may also recompile for given cards only by calling rpmbuild with :
--define "cards card1,card2,card3"
(the default is "cards all")
You may also recompile for a given kernel version and arch with :
--define "kernel <uname -r output>"
(for example "kernel 2.4.20-9")
--target
Mais même avec un système pour "châpeauter" la contruction des rpm, ce n'est pas un système de gestion de dépendance. A moins que USE puisse te dire :
- "compilation/installation de KDE refusé car qt n'est pas disponible"
au-lieu de planter au milieu de la compilation.
> Ça va en faire des versions spécifiques à compiler pour RedHat
Je crois que tu n'as pas bien compris le système. D'une certain manière on peut dire que c'est pour avoir des espaces de paquet séparés et éviter les conflits. Imaginons que ximian utilisé un Epoch=12 par exemple, le paquet nommé toto chez redhat ne va pas interférer avec le paquet toto de de xiniam et quelque soit la version des paquets. Par exemple tu ne peux pas mettre à jour libtoto-1.0-1 de ximian par un libtoto-1.0-2 de redhat si le paquet toto réclame un 12:libtoto . Le "Epoch" est prioritaire. L'objectif n'est pas de compiler des 10 façons différentes le même paquet. Il y a d'autres mécanismes pour ça ("--define", "--with", "--without").
> > Rpm gère les paquets absolètes.
> Pur narcissisme.
Exemple concret. Apache fournit maintenant mod_dav alors qu'avant c'était un paquet séparé. Dans le paquet il y a :
Obsoletes: mod_dav
Le nouveau paquet apache est autorisé à supprimer mod_dav puisqu'il le fourni. Sinon rpm indique un conflit (il ne va pas desinstaller un paquet sans "authorisation") et il faut désinstaller mod_dav avant de mettre le nouveau apache.
C'est aussi utilisé pour changer de version de distribution. Si la distribution passe de wu-ftpd à proftpd, il y aura dans proftpd :
Obsoletes: wu-ftpd
wu-ftpd sera supprimé si proftpd est installé. Ce qui est normal si le distributeur ne veut plus supporter wu-ftpd.
C'est aussi grace à ça que les gens passent de Mandrake 9.0 à 9.1 ou redhat 8.0 à 9 sans tout réinstaller.
C'est toujours du "Pur narcissisme" pour toi ?
> Moi je suis sûr grâce à ton post que bientôt rpm aura rattrapé son retard sur apt.
C'est d'une "naïveté"... apt existe pour rpm.
rpm n'est pas l'équivalent d'apt !
up2date ou urpmi ou yum sont des équivalents d'apt. L'équivalent de rpm dans le monde apt est dpkg.
> vrais paquets virtuels
Fait.
> héritage entre specs
???
> gestion explicite des masques de paquets
???
Tu parles peut-être encore de compilation alors que je parle de gestion de dépendance pour un système rpm qui n'est pas orienté source.
> mélange aisé de 3 niveaux de stabilité des paquets
Fait.
> système de merge des fichiers de conf
Fait, c'est les triggers du paquet qui le font. Du moins si le paquet est développé pour le faire.
> Mais il n'approche qu'à peine (et c'est bien normal, mauvais choix, mauvais résultats) la souplesse que peut offrir un système basé sur les sources ... blabla source compilation etc
rpm n'est pas fait pour faire une distribution orienté source. Comparer rpm à gentoo sur ce point n'a pas de sens.
Par contre il est possible de faire une surcouche à rpm pour faire une distribution orienté source. Les binaires stokent le nom du paquet src.rpm qui stockent ce qui est nécessaire pour la compilation qui est elle-même paramétrable via --define --with --without. Une sourcouche pour "piloter" tout ça est tout a fait envisagable.
Mais avec ça on reste loin de la possilité de faire ça depuis les sources :
$ yum install_build_from_source provides libgnomeui-2.so.0
ou
$ yum install_build_from_source provides /usr/X11R6/bin/xscreensaver-demo
Or ça marche avec les binaires et avec résolution des dépendances. A moins de tout mettre en dure (pas de detections automatiques) ça ne peut pas marcher avec les sources. Tout mettre en dure n'est pas une bonne solution si on ne veut pas système bordélique.
> Alors que franchement, sur une distrib à la redhat, c'est quoi la proportion d'utilisateurs qui ont un jour fait leur propre srpm ?
Je fais mes rpm quand c'est nécessaire (ajout crypto, driver adsl, etc). Je préfère utiliser mon système que d'attendre la fin d'une compilation de 10 heures.
Renseigne toi un peu, les repository pour rpm ne manquent pas :
- http://plf.zarb.org/(...)
- http://dag.wieers.com/home-made/apt/(...)
- http://atrpms.physik.fu-berlin.de/(...)
- http://ftp.falsehope.com/pub/(...)
- http://www.fedora.us/index-main.html(...)
- http://home.teleport.ch/simix/(...)
- http://ccrma-www.stanford.edu/planetccrma/software/(...)
- http://freshrpms.net/(...)
- ...
T'as prouvé ton ignorance complète sur rpm.
Si tu veux une distribution orienté source, reste sous Gentoo. Personne n'a dit que les distributions actuelles basées sur rpm étaient des distributions orientées source.
Si les .rpm et .deb sont sur la place depuis un moment, ce n'est pas un hazard et surement pas à cause de "mauvais choix" comme tu dis.
Mais quels "mauvais choix" ? Tu peux t'expliquer ?
Le "mauvais choix" de n'avoir pas mis la priorité sur les distribution orienté source ?
Réjouis toi alors. Ça garanti un succès fulgurant de gentoo. Mais pour quand ? Car la déferlante on ne la voit pas venir actuellement.