dguihal a écrit 1031 commentaires

s/pain/lapin/ autant que je la sache

Complètement minable comme troll humoristique,

t'aurais plus au moins penser à quelque chose de plus réaliste comme par exemple emacs

~~~~>[]

VMWare viole autant la GPL que NVidia et ATI ( et les autres moins connus) via leur driver propriétaire en mode noyau.

je crois que le s de archives est la pour signaler les dépendances non présentes sur son installation et nécessaires à eog.

A moins que ce ne soient des Gio ?

Eviter de les redistribuer après les avoir exécutées cependant, ce n'est pas toujours de bon goût

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.

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

Je savais pas qu'on pouvait proposer un rapport de bug sur les utilisateurs d'Ubuntu, trop fort ce launchpad.

On peut les patcher aussi ?

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

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.

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)

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 ?

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

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.

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.

Pareil j'utilise les backports depuis qu'ils existent et je n'ai eu que des problèmes très mineurs.

Je me mêle peut-être de ce qui ne me regardes pas mais c'est quoi l'intérêt d'installer cette bouse infâme de quicktime sachant que ffmpeg décode très bien les .mov ?

Ouh Ouh, mon cher Linuce, ardent défenseur d'Ubuntu et de GTK, tu croyais vraiment pouvoir m'avoir aussi simplement sur ton lancé de troll ?
Tu me prends pour un Noob ou quoi ? (En plus t'es complètement a coté de la plaque avec ton interprétation de mon post)


#!/bin/ksh
cat procList | while read line
do
if [ `ps ax | grep $line | wc -l ` -le 1 ] ; then echo "le process $line ne tourne pas." >> Alarme.log ; fi
done


pour le coup du BSD, il s'agit probablement du type de formatage des options du ps ( avec ou sans "-" ce qui dans un cas est a la norme POSIX et de l'autre BSD )

le probleme c'est que les fichiers de conf ne sont plus alors lisibles simplement que par l'outil qui a servi a les creer, on ne peux plus rattraper une grosse boulette avec vim pas exemple

oh un simple et (trop) rapide rm -rf * en se rendant compte (trop tard) que l'on n'était pas dans le dossier voulu est assez efficace.

sinon j'ai vu aussi un subtil chmod -R 0777 à la racine assez ravageur

oui bien sur avec un " ps -A | grep ... "

Suis-je bête, je me suis attaché a la forme et pas au fond,

Comment veux-tu afficher "$NomProc" si celui-ci ne tourne pas ?

De plus le $? risque de faire reference à la commande awk (voire à l'affectation) et non pas au ps

donc

#!/bin/ksh
cat procList | while read line
do
ps $line >/dev/null
if [ $? -eq 1 ] ; then echo "le PID $line ne tourne pas." >> Alarme.log ; fi
done



#!/bin/ksh
cat procList | while read line
do
NomProc=$(ps $line | awk '{print $1}')
if [ $? -eq 1 ] ; then echo "$NomProc ne tourne pas." >> Alarme.log ; fi
done


Ceci suppose que procList contient une liste de PIDs