Il n'y a pas de métapaquet dans Fedora. Il y a un truc de plus haut niveau qui sont les groupes. Oui, ça a le défauts que tu donnes et est principalement intéressant pour l'installation (ça selectionne automatiquement un ensemble de paquet pour un besoin typique de l'utilisateur). NB: c'est un truc que ne voit jamais rpm.
> mais sous Debian, si on active les Recommends
Pour info, Il n'y a pas "Recommends" dans Fedora (suggested a été ajouté à rpm il y a peu, mais Fedora ne l'utilise pas).
> heureusement, par défaut, il n'est pas lancé
Sous Fedora, les serveurs ne sont pas lancés par défaut. Il y a bien quelques exceptions (genre dbus, etc).
> j'avais eu l'expérience de voir l'essentiel d'une appli de création de CD d'install Fedora rester malgré une désinstallation
Ça bouffe de la place disque... Rien d'autres.
> si les dépendances ne sont pas enlevées, en désinstallant kmldonkey, il reste mldonkey-server...
J'ignore les détails, mais ça peut être normal. Par exemple kmldonkey n'est qu'un frontend pour mldonkey-server (ou mldonkey-core). Donc on peut avoir une bécane sans kmldonkey et n'utiliser que mldonkey-server à distance.
En passant, si tu utilises mldonkey, bittorrent, etc qui accèptent des connexions externes, utilises les avec un compte différent que ton compte principal. Linux (X11/tty) c'est nickel pour ça.
Tu peux avoir Firefox sur un serveur. Si tu l'utilise jamais, même si Firefox est ce qu'il y a de pire niveau sécurité (normal vu sa complexité), ce n'est pas un problème.
Si t'as la bétise d'utiliser Firefox, mldonkey, Azureus, etc en root sur un serveur en production... Je ne dis pas que tu le fais, mais la sécurité c'est plus sérieux que de s'assurer que des paquets non utilisés soient désintallés.
> De même, si j'installe cryptkeeper, il me fait venir encfs comme dépendance...
Et ?
Je connais mal cryptkeeper, mais je ne vois pas le problème si cryptkeeper utilise encfs. Si c'est pour installer un truc qui ne marchera pas...
Je ne vois pas en quoi l'installation de encfs est un risque ... surtout si tu l'utilises pas. Et pour qu'un crakeur l'utilise, il faut déjà qu'il est cracké ta bécane.
> il me semble avoir déjà vu des applis supporter libgnutls et libssl en même temps, en se servant de l'une en priorité, quand les deux sont installées.
C'est plus un problème de gestion de la distribution (ou upstream) qu'un problème de gestionnaire de paquet.
Ceci dit, on ne peut pas vraiment te donner tord. Si quelqu'un le fait pour Fedora (je pense plus spécifiquement à PackageKit) ça ne sera peut-être pas refusé.
> Le "formatage" fonctionnaire est fait par "en haut", pas par les gens qui y sont, c'est ça le pire...
Bof. Par en haut et par en bas. Quand t'as un mec en haut qui veut faire bouger les choses (sans brutalité, juste faire bouger les choses à leur rythme normal), t'as les gens en bas qui freinent des quatres fers.
Dans mon dernier boulot, j'ai été impressionné par tout le géni, l'initiative, qui est mise par les gens d'en bas (pas tous !) pour être "peu productif" et/ou justifier leur faible productivité. Et ça bouffe du temps en détail insignifiant, à chipoter ici ou là, etc. Ça bosse globalement, mais c'est inéfficace et c'est fait exprès.
Par contre, ceux qui sont en CDD, etc, ils doivent cravacher (pour le confort des autres).
> J'ai du mal à imaginer une communauté très actif autour de rpm
Ben c'est un problème. S'il n'y a pas Red Hat pour "se sortir les doigts du cul", rpm stagne.
Il a été reproché à Red Hat de ne pas avoir réagit assez vite/fort au départ de Jeff Johnson, mais les autres n'ont quasi rien fait...
Notons que du côté de deb/dpkg ce n'est guère mieux. Il y avait un article sur lwn.net à ce propos, mais j'ai la flemme de le chercher.
Certes il y a des contributions de Novell, Mandriva, etc. Mais sans Red Hat il n'y a pas une communauté pour faire vivre le projet.
> Bref, pour moi, c'est un bug (et un très très gros)...
Faut pas pousser...
J'ai répondu ailleurs, mais un peu à côté de la plaque.
Ce que tu demandes est réalisable, pas de doute (d'ailleurs ça a été fait...).
Mais c'est compliqué et/ou moche, dangereux, etc.
Pour certains paquets (typiquement les librairies), on pourrait avoir un drapeau qui dit "me supprimer si aucun paquet dépend de moi".
On peut avoir un autre système qui est "ne garder que ce qui est demandé explicitement". Lors de l'installation il pourrait y avoir par défaut des paquets explicitement demandés (vim, etc).
C'est réalisable. Mais l'intérêt est faible et une source possible de problème. Par exemple m4 (ou même wget) est rarement un programme demandé explicitement par l'utilisateur. Donc il peut être supprimé si aucun programme en dépend. Mais m4 est aussi un programme pour utilisateur (comme l'est awk, grep, etc). On pourrait avoir une mise à jour qui vire m4 alors que ce dernier est utilisé par un programme (fait pas l'utilisateur). Et si ce programme est pour un serveur... c'est une catastrophe. Il y a le même problème pour les programmes qui ne sont pas gérés par le gestionnaire de paquet (par exemple l'installation d'un tar.gz).
Bref, la sécurité demande qu'on laisse ces paquets (soit disant inutiles) car ils ne gènent pas.
Il y a aussi d'autre trucs subtils. Par exemple les paquets type desktop-backgrounds . Ces paquets ne sont exigé par aucun paquet. Ben oui, c'est seulement pour faire joli. Que fait-on ? On les mets dans les paquets explicitement demandé à l'installation ? Idem pour, par exemple, gnome-vfs2-smb (utilisé en "plugin") ? On ajoute des dépendances explicites ? Par exemple gnome-desktop dépend de desktop-backgrounds. Mais si un utilisateur veut virer desktop-backgrounds...
C'est lourd à gérer.
Ceci (et on peut trouver d'autres cas où ça sucks (par exemple les paquet *-devel), plus le fait que c'est d'un intérêt très limité et parfois dangereux, fait que pour certains ce n'est pas du tout un "très très gros bug" ni une feature intéressante et donc rien est fait (en tout cas chez Fedora).
Pour toi c'est peut-être une super importante "feature" car tu installes et désintalles plein de programmes. Mais ce n'est pas un usage courrant de GNU/Linux (sauf peut-être pour les moules dlfp).
M'enfin, pourquoi ?
Le seul intérêt du truc est de gagner quelques Mo sur le disque dur. Il n'y a pas de perte de performance à garder des librairies qui ne servent à rien. Peut-être que le plus pénalisant est la mise à jour de librairie qui ne sont pas utilisée (téléchargement inutile).
L'intérêt est faible et ça peut donner quelques surprises pour ce que n'est pas librairies.
Principalement car je ne comprennais pas ton raisonnement qui était d'accuser avant même d'avoir creusé le problème. Je me suis dit que tu avais une "culture" fonctionnaire. Dans le privé, globalement, on exige un minimum dans les prestations de l'employer. Chez les fonctionnaires on insite à la bonne prestation, c'est moin une exigence.
J'ai déjà bossé dans des administrations publics, et la culture y est "bizarre".
Ne faison pas passer Jeff Johnson pour un vilain méchant. Il n'est pas parti dans une "croisade" contre son ex-employeur, il n'a pas fait de "sabotage", etc.
Il n'y avait pas accord en Jeff Johnson et Red Hat et les parties se sont séparées sans heurt.
Bref, Jeff Johnson reste quelqu'un de très respectable.
Notons que Jeff Johnson a été prévenu. Ça a pris longtemps pour qu'il soit viré. Et, fait important, il ne s'en est pas plaint. Il n'a pas voulu respecter les consignes de son employeur, il l'avoue, il a été viré.
Sauf si on est fonctionnaire, ça ne prète pas vraiment à discussion.
> Red Hat, ou les ayant droit auraient-ils la possibilité d'attaquer rpm5.org pour usurpation d'identité
Rpm n'est pas une marque déposée (et ne peut plus l'être maintenant).
Enfin Jeff Johnson a énormemment travaillé sur rpm et en a autant la "paternité" que Red Hat.
Il y a eu discussion entre Red Hat et Jeff Johnson sur ce point. Il a dit qu'il laisserait Red Hat tranquille et vice versa.
Ça montre l'importance de déposer une marque... ou l'inverse puisqu'il n'y a pas de gros problèmes pour ce cas.
On peut trouver plein de défaut à Vista. J'ai donné seulement un avis d'utilisateur.
L'utilisateur il va à la fnac et il achete un truc avec 2 Go de mémoire (en fait il l'ignore...) et Vista.
> Mais le système en 32 bits
Truc rigolo.
J'ai un GNU/Linux 64 bits et un Vista 32 bits. Au début les deux avaient 2 Go. Ben maintenant il y a 1 Go pour GNU/Linux (alors qu'il est 64 bits) et 3 Go pour Vista. En gros il faut 3 fois plus de mémoire pour Vista.
Désolé alors.
Je crois que les .deb sont des fichiers .ar .
> Dans le cas ou j'ai eu a faire une modif,
T'as raison, pouvoir "exporter/importer" un rpm peut être sympa dans certains cas.
Ce qui m'a énervé est que tu conclus que rpm est "mal foutu" car il ne le permet pas (actuellement).
En passant toutes les distributions permettent de proprement refaire un paquet (c'est fait en chroot). Par exemple sous Fedora pour faire un paquet : "mock --rebuild --arch=fedora-8-i386 --target=i686 paquet.src.rpm".
Pas difficile, mais plus compliqué que ce que tu proposes. Mais ça permet tout.
> Sinon l'UAC je suis d'accord c'est un gros plus.
Surtout avec un compte "standard" et non admin. En fait UAC avec un compte standard en presque sans intérêt avec un compte standard puisque l'action est interdite. Mais ça donne la possibilité de basculer en "administrateur" (si on a le mot de passe qui va bien).
Certe, c'est complètement pourri par rapport à GNU/Linux (qui en plus à l'excellent PolicyKit). M'enfin, par rapport à XP c'est nettement mieux. Pas très pratique, mais ça évite d'avoir le bordel sur son poste. Au pire le compte est bousillé, il suffit d'en créer un autre.
> Relis mon poste, je parles des informations en plus qu'a un rpm (numéro de version, dépendances, etc) et que toutes ces informations pourraient être stockées dans un fichier.
Oui elles pourraient (être exportées dans un fichier). Mais ce n'est pas le cas.
Je n'ai pas dit qu'il y avait des raisons techniques à ça. C'est simplement car ça ne colle pas à l'usage de rpm.
Si tu veux faire un outils qui exporte/importe en fichiers (avec un __META__/* pour tous les trucs qui ne sont pas des fichiers) , n'hésites pas.
Pourquoi ça n'a pas encore été fait ?
Parce que quasiment tout le monde s'en fout.
En passant, il y a rpm2cpio qui n'extrait que les fichiers (pour les fichiers spéciaux il faut être root).
Il y a "rpm -q --dump" pour avoir les attributs des fichiers (mode, doc/config, etc).
Il y a "rpm -q --scripts" pour avoir les scripts.
Il y a "rpm -q --triggers" pour avoir les triggers.
Il y a "rpm -q --requires", "rpm -q --provides" et "rpm -q --conflits" pour les dépendances.
Pour les attributs du paquet (version, licences, date de création, etc), il suffit d'utiliser "rpm --querytags" pour avoir les noms des champs et "rpm -q --queryformat" pour avoir les valeurs.
Tu rassembles tout ça, le passe à la moulinet, et crée un fichier .spec pour... recréer le fichier .src.rpm pour... finir comme tout le monde par utiliser rpmbuild (m'enfin tu n'auras pas besoin de recompiler le paquet).
> 1) Ca te parait simple comme manipulation?
Si tu en es à vouloir modifier un paquet, alors tu ne fais pas un truc simple. Dans ce cas, oui c'est assez simple de modifier le src.rpm. Ça peut par contre bouffer du temps et de l'espace disque.
> Meme quand il s'agit de changer un fichier de données/script inchangé entre le rpm et le src.rpm?
Et ?
Oui parfois on refait un paquet depuis le src.rpm seulement pour un ligne ou car il y a un typo dans ligne.
Mais c'est quoi rpm ? C'est quoi l'objectif ?
C'est, entre autre, d'avoir toutes la procedure de création du paquet. Si tu fais des "bidouilles" avec le paquet à installer, tu perds ça.
Si tu veux bidouiller, utilise un bon vieux "./configure && make ..."
> 2)Et pourquoi faire une différence entre un src.rpm et un rpm?
Ce n'est pas la même chose, la même fonction. Un src.rpm ne s'installe pas, il n'est pas dans base rpm (dans /var/lib/rpm). Un src.rpm n'a pas de dépendance, n'a pas de scripts a exécuter à l'installation, ne demande pas le compte root pour être installé, etc. Bref, sa fonction est bien différente, c'est seulement un conteneur (comme un tar/cpio).
Un paquet rpm est un truc construit par le programme rpm (en fait rpmbuild qui fait aussi divers contrôle) pour être installé sur un système (vérification des dépences, des conflits entre fichiers, définit le propriétaire de fichier (donc doit être root), etc). Le src.rpm est aussi construit par rpmbuild, mais il ne fait rien d'autres que d'"empiler" des fichiers dans un src.rpm. rpm exige d'être root, on peut construire un .rpm sans être root.
D'ailleur on peut faire des rpm depuis un fichier tar (il doit avoir un fichier .spec dedans). Suffit de faire rpmbuild -tb toto.tar. Donc les fichiers sources des rpm pourrait très bien être des tar, pas de problème à ça sauf petites bricoles (pas de signature, etc).
> Pour moi, les deux devraient avoir une structure identique et juste être différent au niveau du contenu
C'est le cas. C'est le même outils pour faire un src.rpm et un rpm.
> modifier un src.rpm est simple mais pas un rpm, donc je trouve ça mal fichu..
Ben modifie un src.rpm...
Et après ?
Ben fait les rpm car ton src.rpm tu ne peux pas l'installer...
> donc je trouve ça mal fichu..
Ben il y en a très très très très peu qui utilise rpm et ont ton "problème".
Mais je pense que tu dois tomber à genoux devant le format .deb qui le permet...
Suffisait de le dire. +0.00001 pour .deb.
Un paquet rpm n'est pas équivalent à tar ou cpio. Sinon autant utiliser ces derniers.
M'enfin, un src.rpm (le paquet source rpm qui crée le paquet installable) peut-être vu comme un tar/cpio.
Si tu veux modifier un .rpm, fait comme tout le monde, prend le src.rpm et reconstruit le paquet.
Juste pour test, amusez vous à copier un compte utilisateur. Ça ne marchera pas...
En plus MS dit que c'est fait pour synchroniser deux répertoires. Attention ce n'est pas rsync ! Dans ce cas ça supprimer tous les fichiers dans le répertoire de destination avant de faire la copie !
Truc rigolo, et comme il ne sait pas gérer les liens symboliques, il peut tomber sur sur un truc circulaire. On peut t'attendre à ce qu'il laisse tomber. Ben non, robocopy fait une pause de 30 secondes et recommence...
Minable ce truc.
> Souvent lorsque je cherche une option dans le panneau de configurations
J'ai un avis contraire. Je trouve le panneau de configuration bien foutu. Il suffit de lire ce qui est écrit et en cheminant tranquillement on trouve (en général). Certes il y a des trucs qui sont bien tordus à trouver.
> Bref, c'est une usine à gaz.
Le panneau de configuration sous Vista est un "centre de guidage". Il y a plusieurs façons pour accéder à une option. Si on veut y trouver un logique "carrée", ce n'est pas possible, mais ce n'est pas son but et c'est son intérêt. C'est adapté à quelqu'un qui ne connait pas le système. Il y a plusieurs étapes (c'est intentionnel) afin que l'utilisateur arrive à ce qu'il veut en répondant plus ou moins à des questions.
Perso, je n'utilise pas l'affichage classique.
Le panneau peut être déroutant, mais MS y a fait beaucoup de boulot afin de "guider" l'utilisateur.
> De plus ils ont gardé encore leur idée de cacher les extensions de fichier par défaut, bonne chose pour activer de façon sympa le virus caché dans britney.jpg.exe
Dans ce cas le type de fichier est "application" et non image. De plus sous Vista, si on laisse le "contrôle des comptes utilisateurs" (je le conseille), par défaut on ne peut pas excécuter un programme qui n'est pas installé. Il y a un gros avertissement avant de lancer le programme.
Enfin, et je le conseille, Vista est tout à fait utilisable avec un compte non-admin. Sous XP c'était quasi insupportable.
> une collègue, novice en informatique, m'a porté l'autre jour son ordinateur parce que "le premier jour elle avait une icône d'internet (c.a.d internet exploreur) sur le bureau, et maintenant elle l'a perdu
"Panneau de configuration" => "Apparence et Personnalisation" => "Personnalisation" => "Changer les icones du bureau" (sur la gauche).
En fait, il n'y a pas IE sur le bureau dans Vista...
Donc si c'est un raccourcis, il suffit de le glisser du menu sur le bureau. Et voilà.
> De plus ils ont gardé encore leur idée de cacher les extensions de fichier par défaut
Bof...
Es-ce une mauvaise idée qu'Unix n'utilise pas les extensions de fichier ?
> Leur nettoyage automatique du bureau au bout de 60 jours
BIzarre, je ne l'ai jamais vu...
Faut dire que je n'ai pas grand chose sur mon bureau.
> De plus, il y a vraiment des bugs étranges
C'est clair que Windows reste toujours "woodoo". J'ai eu des trucs inexplicables. Par exemple je mets un partage pour transférer un gros fichier, sur l'autre bécane je copie le fichier. Puis quelques secondes après, BOOM, je ne peux plus copier, il me dit que je n'en ai pas le droit. Si je reboote, ça marche (pour un temps...).
Insupportable !
Autres trucs "rigolo", je supprime souvant les fichiers avec <shift><suppr> (pour ne pas passer par la corbeille). S'il y a une arborescence assez profonde, Vista plante lors de la suppression des fichiers. Si je passe par le corbeille, ça marche. Du moins parfois. Une fois j'ai du utiliser robocopy (option /purge) pour virer un répertoire. Ce programme robocopy (écrit par MS) n'est pas foutu de gérer les liens symboliques (introduit dans Vista). Et MS appelle ça "Robust File Copy".
Bref, Vista sucks sur bien des points dès qu'on veut "jouer" avec cratter un peu.
Une fois j'ai booter sous GNU/Linux uniquement pour copier des fichiers de NTFS à NTFS...
> Les distributions utilisant RPM n'ont jamais voulu utiliser la branche de Jeff Johnson
Sauf Mandriva notablement (et peut-être pld ?). http://lists.mandriva.com//cooker/2007-05/msg03701.php
Il me semble que c'est dans la semaine de création de rpm5 que Mandriva a décidé d'utiliser rpm5 et abandonner rpm.
Rpm 4.6 est une version de "nettoyage". Mais beaucoup de boulot y a été fait.
Les versions suivantes seront plus innovantes.
Je n'avais pas vraiment envis de faire un journal sur Vista.
Mais j'utilise Vista depuis 4 mois environ. J'ai lu des tonnes de commantaire ici qui chient sur Vista. Etant d'avis contraire à ce que se dit ici, j'ai décidé de le dire même si ma motivation n'était pas élevée. Je voulais principalement dire ce que dit le titre du journal : "Vista, moins pire qu'on le dit". C'est tout, mais il fallait bien que j'argumente un peu.
Il y a du hors sujet, mais le "bouh, KDE copie sur Vista (ou l'inverse)" m'énerve.
Enfin, il est "dangereux" de dire du bien de Windows, sinon les gens croient qu'il faut faire comme Windows. Or je ne le pense pas, et il fallait aussi que je l'explique (même mal).
> c'est justement la philosophie de Vista qui fait augmenter exponentiellement les vente de Mac tellement elle est pourrie.
Et si simplement c'était les qualités de Mac ?
Et si simplement les gens ont envis d'avoir autre chose que l'omniprésent Windows et que Mac est la meilleur alternative (pour un "consommateur") ?
J'aime le libre, et rien ne me ferait plus plaisir qu'un Windows bien pourri. Malheureusement, ce n'est pas le cas.
> Super, je parie que si on leur avait montré rapidement un MacOS avec un fond d'écran foncé en leur disant que c'était Windows 7 ils auraient "Waouh super ce nouveau Windows".
Si tu veux.
Ça montre que ce "test" est totalement débile.
En passant, MS a fait preque la même chose. MS a pris un Vista mais sans dire que c'était un Vista. Ben les utilisateurs ont trouvé ce "nouveau" système génial...
Miser sur l'ignorance des gens pour tirer des conclusions souhaitées est une honte.
[^] # Re: Et sinon...
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 2.
Il n'y a pas de métapaquet dans Fedora. Il y a un truc de plus haut niveau qui sont les groupes. Oui, ça a le défauts que tu donnes et est principalement intéressant pour l'installation (ça selectionne automatiquement un ensemble de paquet pour un besoin typique de l'utilisateur). NB: c'est un truc que ne voit jamais rpm.
> mais sous Debian, si on active les Recommends
Pour info, Il n'y a pas "Recommends" dans Fedora (suggested a été ajouté à rpm il y a peu, mais Fedora ne l'utilise pas).
> heureusement, par défaut, il n'est pas lancé
Sous Fedora, les serveurs ne sont pas lancés par défaut. Il y a bien quelques exceptions (genre dbus, etc).
> j'avais eu l'expérience de voir l'essentiel d'une appli de création de CD d'install Fedora rester malgré une désinstallation
Ça bouffe de la place disque... Rien d'autres.
> si les dépendances ne sont pas enlevées, en désinstallant kmldonkey, il reste mldonkey-server...
J'ignore les détails, mais ça peut être normal. Par exemple kmldonkey n'est qu'un frontend pour mldonkey-server (ou mldonkey-core). Donc on peut avoir une bécane sans kmldonkey et n'utiliser que mldonkey-server à distance.
En passant, si tu utilises mldonkey, bittorrent, etc qui accèptent des connexions externes, utilises les avec un compte différent que ton compte principal. Linux (X11/tty) c'est nickel pour ça.
Tu peux avoir Firefox sur un serveur. Si tu l'utilise jamais, même si Firefox est ce qu'il y a de pire niveau sécurité (normal vu sa complexité), ce n'est pas un problème.
Si t'as la bétise d'utiliser Firefox, mldonkey, Azureus, etc en root sur un serveur en production... Je ne dis pas que tu le fais, mais la sécurité c'est plus sérieux que de s'assurer que des paquets non utilisés soient désintallés.
> De même, si j'installe cryptkeeper, il me fait venir encfs comme dépendance...
Et ?
Je connais mal cryptkeeper, mais je ne vois pas le problème si cryptkeeper utilise encfs. Si c'est pour installer un truc qui ne marchera pas...
Je ne vois pas en quoi l'installation de encfs est un risque ... surtout si tu l'utilises pas. Et pour qu'un crakeur l'utilise, il faut déjà qu'il est cracké ta bécane.
> il me semble avoir déjà vu des applis supporter libgnutls et libssl en même temps, en se servant de l'une en priorité, quand les deux sont installées.
C'est plus un problème de gestion de la distribution (ou upstream) qu'un problème de gestionnaire de paquet.
Ceci dit, on ne peut pas vraiment te donner tord. Si quelqu'un le fait pour Fedora (je pense plus spécifiquement à PackageKit) ça ne sera peut-être pas refusé.
M'enfin, tu fais de l'"enculage de mouche".
[^] # Re: Ah... Les fonctionnaires!
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 3.
Bof. Par en haut et par en bas. Quand t'as un mec en haut qui veut faire bouger les choses (sans brutalité, juste faire bouger les choses à leur rythme normal), t'as les gens en bas qui freinent des quatres fers.
Dans mon dernier boulot, j'ai été impressionné par tout le géni, l'initiative, qui est mise par les gens d'en bas (pas tous !) pour être "peu productif" et/ou justifier leur faible productivité. Et ça bouffe du temps en détail insignifiant, à chipoter ici ou là, etc. Ça bosse globalement, mais c'est inéfficace et c'est fait exprès.
Par contre, ceux qui sont en CDD, etc, ils doivent cravacher (pour le confort des autres).
[^] # Re: fusion des différents RPM
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 2.
Ben c'est un problème. S'il n'y a pas Red Hat pour "se sortir les doigts du cul", rpm stagne.
Il a été reproché à Red Hat de ne pas avoir réagit assez vite/fort au départ de Jeff Johnson, mais les autres n'ont quasi rien fait...
Notons que du côté de deb/dpkg ce n'est guère mieux. Il y avait un article sur lwn.net à ce propos, mais j'ai la flemme de le chercher.
Certes il y a des contributions de Novell, Mandriva, etc. Mais sans Red Hat il n'y a pas une communauté pour faire vivre le projet.
[^] # Re: Et sinon...
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 1.
Faut pas pousser...
J'ai répondu ailleurs, mais un peu à côté de la plaque.
Ce que tu demandes est réalisable, pas de doute (d'ailleurs ça a été fait...).
Mais c'est compliqué et/ou moche, dangereux, etc.
Pour certains paquets (typiquement les librairies), on pourrait avoir un drapeau qui dit "me supprimer si aucun paquet dépend de moi".
On peut avoir un autre système qui est "ne garder que ce qui est demandé explicitement". Lors de l'installation il pourrait y avoir par défaut des paquets explicitement demandés (vim, etc).
C'est réalisable. Mais l'intérêt est faible et une source possible de problème. Par exemple m4 (ou même wget) est rarement un programme demandé explicitement par l'utilisateur. Donc il peut être supprimé si aucun programme en dépend. Mais m4 est aussi un programme pour utilisateur (comme l'est awk, grep, etc). On pourrait avoir une mise à jour qui vire m4 alors que ce dernier est utilisé par un programme (fait pas l'utilisateur). Et si ce programme est pour un serveur... c'est une catastrophe. Il y a le même problème pour les programmes qui ne sont pas gérés par le gestionnaire de paquet (par exemple l'installation d'un tar.gz).
Bref, la sécurité demande qu'on laisse ces paquets (soit disant inutiles) car ils ne gènent pas.
Il y a aussi d'autre trucs subtils. Par exemple les paquets type desktop-backgrounds . Ces paquets ne sont exigé par aucun paquet. Ben oui, c'est seulement pour faire joli. Que fait-on ? On les mets dans les paquets explicitement demandé à l'installation ? Idem pour, par exemple, gnome-vfs2-smb (utilisé en "plugin") ? On ajoute des dépendances explicites ? Par exemple gnome-desktop dépend de desktop-backgrounds. Mais si un utilisateur veut virer desktop-backgrounds...
C'est lourd à gérer.
Ceci (et on peut trouver d'autres cas où ça sucks (par exemple les paquet *-devel), plus le fait que c'est d'un intérêt très limité et parfois dangereux, fait que pour certains ce n'est pas du tout un "très très gros bug" ni une feature intéressante et donc rien est fait (en tout cas chez Fedora).
Pour toi c'est peut-être une super importante "feature" car tu installes et désintalles plein de programmes. Mais ce n'est pas un usage courrant de GNU/Linux (sauf peut-être pour les moules dlfp).
Le quoi est : on s'en fout.
[^] # Re: Et sinon...
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 1.
M'enfin, pourquoi ?
Le seul intérêt du truc est de gagner quelques Mo sur le disque dur. Il n'y a pas de perte de performance à garder des librairies qui ne servent à rien. Peut-être que le plus pénalisant est la mise à jour de librairie qui ne sont pas utilisée (téléchargement inutile).
L'intérêt est faible et ça peut donner quelques surprises pour ce que n'est pas librairies.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 2.
Principalement car je ne comprennais pas ton raisonnement qui était d'accuser avant même d'avoir creusé le problème. Je me suis dit que tu avais une "culture" fonctionnaire. Dans le privé, globalement, on exige un minimum dans les prestations de l'employer. Chez les fonctionnaires on insite à la bonne prestation, c'est moin une exigence.
J'ai déjà bossé dans des administrations publics, et la culture y est "bizarre".
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 3.
Il n'y avait pas accord en Jeff Johnson et Red Hat et les parties se sont séparées sans heurt.
Bref, Jeff Johnson reste quelqu'un de très respectable.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 4.
Sauf si on est fonctionnaire, ça ne prète pas vraiment à discussion.
[^] # Re: usurpation d'identité
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 2.
Rpm n'est pas une marque déposée (et ne peut plus l'être maintenant).
Enfin Jeff Johnson a énormemment travaillé sur rpm et en a autant la "paternité" que Red Hat.
Il y a eu discussion entre Red Hat et Jeff Johnson sur ce point. Il a dit qu'il laisserait Red Hat tranquille et vice versa.
Ça montre l'importance de déposer une marque... ou l'inverse puisqu'il n'y a pas de gros problèmes pour ce cas.
[^] # Re: Rpm mal fichu?
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 0.
[^] # Re: Quantité de mémoire vive
Posté par IsNotGood . En réponse au journal Vista, moins pire qu'on le dit. Évalué à 2.
L'utilisateur il va à la fnac et il achete un truc avec 2 Go de mémoire (en fait il l'ignore...) et Vista.
> Mais le système en 32 bits
Truc rigolo.
J'ai un GNU/Linux 64 bits et un Vista 32 bits. Au début les deux avaient 2 Go. Ben maintenant il y a 1 Go pour GNU/Linux (alors qu'il est 64 bits) et 3 Go pour Vista. En gros il faut 3 fois plus de mémoire pour Vista.
[^] # Re: Rpm mal fichu?
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 3.
Désolé alors.
Je crois que les .deb sont des fichiers .ar .
> Dans le cas ou j'ai eu a faire une modif,
T'as raison, pouvoir "exporter/importer" un rpm peut être sympa dans certains cas.
Ce qui m'a énervé est que tu conclus que rpm est "mal foutu" car il ne le permet pas (actuellement).
En passant toutes les distributions permettent de proprement refaire un paquet (c'est fait en chroot). Par exemple sous Fedora pour faire un paquet : "mock --rebuild --arch=fedora-8-i386 --target=i686 paquet.src.rpm".
Pas difficile, mais plus compliqué que ce que tu proposes. Mais ça permet tout.
[^] # Re: On en reparle dans 1 an et demi...
Posté par IsNotGood . En réponse au journal Vista, moins pire qu'on le dit. Évalué à 2.
Surtout avec un compte "standard" et non admin. En fait UAC avec un compte standard en presque sans intérêt avec un compte standard puisque l'action est interdite. Mais ça donne la possibilité de basculer en "administrateur" (si on a le mot de passe qui va bien).
Certe, c'est complètement pourri par rapport à GNU/Linux (qui en plus à l'excellent PolicyKit). M'enfin, par rapport à XP c'est nettement mieux. Pas très pratique, mais ça évite d'avoir le bordel sur son poste. Au pire le compte est bousillé, il suffit d'en créer un autre.
[^] # Re: Rpm mal fichu?
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 4.
Oui elles pourraient (être exportées dans un fichier). Mais ce n'est pas le cas.
Je n'ai pas dit qu'il y avait des raisons techniques à ça. C'est simplement car ça ne colle pas à l'usage de rpm.
Si tu veux faire un outils qui exporte/importe en fichiers (avec un __META__/* pour tous les trucs qui ne sont pas des fichiers) , n'hésites pas.
Pourquoi ça n'a pas encore été fait ?
Parce que quasiment tout le monde s'en fout.
En passant, il y a rpm2cpio qui n'extrait que les fichiers (pour les fichiers spéciaux il faut être root).
Il y a "rpm -q --dump" pour avoir les attributs des fichiers (mode, doc/config, etc).
Il y a "rpm -q --scripts" pour avoir les scripts.
Il y a "rpm -q --triggers" pour avoir les triggers.
Il y a "rpm -q --requires", "rpm -q --provides" et "rpm -q --conflits" pour les dépendances.
Pour les attributs du paquet (version, licences, date de création, etc), il suffit d'utiliser "rpm --querytags" pour avoir les noms des champs et "rpm -q --queryformat" pour avoir les valeurs.
Tu rassembles tout ça, le passe à la moulinet, et crée un fichier .spec pour... recréer le fichier .src.rpm pour... finir comme tout le monde par utiliser rpmbuild (m'enfin tu n'auras pas besoin de recompiler le paquet).
> 1) Ca te parait simple comme manipulation?
Si tu en es à vouloir modifier un paquet, alors tu ne fais pas un truc simple. Dans ce cas, oui c'est assez simple de modifier le src.rpm. Ça peut par contre bouffer du temps et de l'espace disque.
> Meme quand il s'agit de changer un fichier de données/script inchangé entre le rpm et le src.rpm?
Et ?
Oui parfois on refait un paquet depuis le src.rpm seulement pour un ligne ou car il y a un typo dans ligne.
Mais c'est quoi rpm ? C'est quoi l'objectif ?
C'est, entre autre, d'avoir toutes la procedure de création du paquet. Si tu fais des "bidouilles" avec le paquet à installer, tu perds ça.
Si tu veux bidouiller, utilise un bon vieux "./configure && make ..."
> 2)Et pourquoi faire une différence entre un src.rpm et un rpm?
Ce n'est pas la même chose, la même fonction. Un src.rpm ne s'installe pas, il n'est pas dans base rpm (dans /var/lib/rpm). Un src.rpm n'a pas de dépendance, n'a pas de scripts a exécuter à l'installation, ne demande pas le compte root pour être installé, etc. Bref, sa fonction est bien différente, c'est seulement un conteneur (comme un tar/cpio).
Un paquet rpm est un truc construit par le programme rpm (en fait rpmbuild qui fait aussi divers contrôle) pour être installé sur un système (vérification des dépences, des conflits entre fichiers, définit le propriétaire de fichier (donc doit être root), etc). Le src.rpm est aussi construit par rpmbuild, mais il ne fait rien d'autres que d'"empiler" des fichiers dans un src.rpm. rpm exige d'être root, on peut construire un .rpm sans être root.
D'ailleur on peut faire des rpm depuis un fichier tar (il doit avoir un fichier .spec dedans). Suffit de faire rpmbuild -tb toto.tar. Donc les fichiers sources des rpm pourrait très bien être des tar, pas de problème à ça sauf petites bricoles (pas de signature, etc).
> Pour moi, les deux devraient avoir une structure identique et juste être différent au niveau du contenu
C'est le cas. C'est le même outils pour faire un src.rpm et un rpm.
> modifier un src.rpm est simple mais pas un rpm, donc je trouve ça mal fichu..
Ben modifie un src.rpm...
Et après ?
Ben fait les rpm car ton src.rpm tu ne peux pas l'installer...
> donc je trouve ça mal fichu..
Ben il y en a très très très très peu qui utilise rpm et ont ton "problème".
Mais je pense que tu dois tomber à genoux devant le format .deb qui le permet...
Suffisait de le dire. +0.00001 pour .deb.
[^] # Re: Re:
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 3.
[^] # Re: Rpm mal fichu?
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 3.
M'enfin, un src.rpm (le paquet source rpm qui crée le paquet installable) peut-être vu comme un tar/cpio.
Si tu veux modifier un .rpm, fait comme tout le monde, prend le src.rpm et reconstruit le paquet.
[^] # Re: arf
Posté par IsNotGood . En réponse au journal Vista, moins pire qu'on le dit. Évalué à 2.
Vraiment minable.
[^] # Re: arf
Posté par IsNotGood . En réponse au journal Vista, moins pire qu'on le dit. Évalué à 3.
Juste pour test, amusez vous à copier un compte utilisateur. Ça ne marchera pas...
En plus MS dit que c'est fait pour synchroniser deux répertoires. Attention ce n'est pas rsync ! Dans ce cas ça supprimer tous les fichiers dans le répertoire de destination avant de faire la copie !
Truc rigolo, et comme il ne sait pas gérer les liens symboliques, il peut tomber sur sur un truc circulaire. On peut t'attendre à ce qu'il laisse tomber. Ben non, robocopy fait une pause de 30 secondes et recommence...
Minable ce truc.
[^] # Re: arf
Posté par IsNotGood . En réponse au journal Vista, moins pire qu'on le dit. Évalué à 1.
J'ai un avis contraire. Je trouve le panneau de configuration bien foutu. Il suffit de lire ce qui est écrit et en cheminant tranquillement on trouve (en général). Certes il y a des trucs qui sont bien tordus à trouver.
> Bref, c'est une usine à gaz.
Le panneau de configuration sous Vista est un "centre de guidage". Il y a plusieurs façons pour accéder à une option. Si on veut y trouver un logique "carrée", ce n'est pas possible, mais ce n'est pas son but et c'est son intérêt. C'est adapté à quelqu'un qui ne connait pas le système. Il y a plusieurs étapes (c'est intentionnel) afin que l'utilisateur arrive à ce qu'il veut en répondant plus ou moins à des questions.
Perso, je n'utilise pas l'affichage classique.
Le panneau peut être déroutant, mais MS y a fait beaucoup de boulot afin de "guider" l'utilisateur.
> De plus ils ont gardé encore leur idée de cacher les extensions de fichier par défaut, bonne chose pour activer de façon sympa le virus caché dans britney.jpg.exe
Dans ce cas le type de fichier est "application" et non image. De plus sous Vista, si on laisse le "contrôle des comptes utilisateurs" (je le conseille), par défaut on ne peut pas excécuter un programme qui n'est pas installé. Il y a un gros avertissement avant de lancer le programme.
Enfin, et je le conseille, Vista est tout à fait utilisable avec un compte non-admin. Sous XP c'était quasi insupportable.
> une collègue, novice en informatique, m'a porté l'autre jour son ordinateur parce que "le premier jour elle avait une icône d'internet (c.a.d internet exploreur) sur le bureau, et maintenant elle l'a perdu
"Panneau de configuration" => "Apparence et Personnalisation" => "Personnalisation" => "Changer les icones du bureau" (sur la gauche).
En fait, il n'y a pas IE sur le bureau dans Vista...
Donc si c'est un raccourcis, il suffit de le glisser du menu sur le bureau. Et voilà.
> De plus ils ont gardé encore leur idée de cacher les extensions de fichier par défaut
Bof...
Es-ce une mauvaise idée qu'Unix n'utilise pas les extensions de fichier ?
> Leur nettoyage automatique du bureau au bout de 60 jours
BIzarre, je ne l'ai jamais vu...
Faut dire que je n'ai pas grand chose sur mon bureau.
> De plus, il y a vraiment des bugs étranges
C'est clair que Windows reste toujours "woodoo". J'ai eu des trucs inexplicables. Par exemple je mets un partage pour transférer un gros fichier, sur l'autre bécane je copie le fichier. Puis quelques secondes après, BOOM, je ne peux plus copier, il me dit que je n'en ai pas le droit. Si je reboote, ça marche (pour un temps...).
Insupportable !
Autres trucs "rigolo", je supprime souvant les fichiers avec <shift><suppr> (pour ne pas passer par la corbeille). S'il y a une arborescence assez profonde, Vista plante lors de la suppression des fichiers. Si je passe par le corbeille, ça marche. Du moins parfois. Une fois j'ai du utiliser robocopy (option /purge) pour virer un répertoire. Ce programme robocopy (écrit par MS) n'est pas foutu de gérer les liens symboliques (introduit dans Vista). Et MS appelle ça "Robust File Copy".
Bref, Vista sucks sur bien des points dès qu'on veut "jouer" avec cratter un peu.
Une fois j'ai booter sous GNU/Linux uniquement pour copier des fichiers de NTFS à NTFS...
[^] # Re: fusion des différents RPM
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 3.
Non. Jeff Johnson a été viré par Red Hat. Ajoutons que Jeff n'était pas vraiment contre :-)
> peut être que redhat a voulu créer un vrai rpm communautaire
Oui. Mais constatons que ça ne prend pas. Red Hat fait toujours le gros du boulot et a du embaucher spécifiquement pour rpm.
> Peut être qu' il s' agit d' une stratégie parfaitement entendue entre Jeff Jonhson et Redhat. Peut être que je raconte n' importe quoi.
=> n'importe quoi.
> il me semble que les exemples de refus de redhat d' ajout de fonctions et de patchs dans rpm fait par des contributeurs, étaient assez courant :(
Admettons. Rpm est un élément critique et donc tout n'y est pas permis.
Linus aussi refuse beaucoup de chose...
[^] # Re: C'est utilisé ?
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 9.
http://fr2.rpmfind.net/linux/fedora/releases/10/Everything/s(...)
Si rpm est utilisé pour du contenu et non seulement des programmes, les 2 Go peuvent être dépassé.
# Re:
Posté par IsNotGood . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 4.
Sauf Mandriva notablement (et peut-être pld ?).
http://lists.mandriva.com//cooker/2007-05/msg03701.php
Il me semble que c'est dans la semaine de création de rpm5 que Mandriva a décidé d'utiliser rpm5 et abandonner rpm.
Rpm 4.6 est une version de "nettoyage". Mais beaucoup de boulot y a été fait.
Les versions suivantes seront plus innovantes.
En passant F10 a rpm 4.6 (une rc).
[^] # Re: Et?
Posté par IsNotGood . En réponse au journal Vista, moins pire qu'on le dit. Évalué à 5.
Je n'avais pas vraiment envis de faire un journal sur Vista.
Mais j'utilise Vista depuis 4 mois environ. J'ai lu des tonnes de commantaire ici qui chient sur Vista. Etant d'avis contraire à ce que se dit ici, j'ai décidé de le dire même si ma motivation n'était pas élevée. Je voulais principalement dire ce que dit le titre du journal : "Vista, moins pire qu'on le dit". C'est tout, mais il fallait bien que j'argumente un peu.
Il y a du hors sujet, mais le "bouh, KDE copie sur Vista (ou l'inverse)" m'énerve.
Enfin, il est "dangereux" de dire du bien de Windows, sinon les gens croient qu'il faut faire comme Windows. Or je ne le pense pas, et il fallait aussi que je l'explique (même mal).
> c'est justement la philosophie de Vista qui fait augmenter exponentiellement les vente de Mac tellement elle est pourrie.
Et si simplement c'était les qualités de Mac ?
Et si simplement les gens ont envis d'avoir autre chose que l'omniprésent Windows et que Mac est la meilleur alternative (pour un "consommateur") ?
J'aime le libre, et rien ne me ferait plus plaisir qu'un Windows bien pourri. Malheureusement, ce n'est pas le cas.
[^] # Re: arf
Posté par IsNotGood . En réponse au journal Vista, moins pire qu'on le dit. Évalué à 2.
Très juste.
Et d'accord avec tout le reste :-)
[^] # Re: Pas très observateur
Posté par IsNotGood . En réponse à la dépêche Est-ce Windows 7 ou KDE 4?. Évalué à 4.
Si tu veux.
Ça montre que ce "test" est totalement débile.
En passant, MS a fait preque la même chose. MS a pris un Vista mais sans dire que c'était un Vista. Ben les utilisateurs ont trouvé ce "nouveau" système génial...
Miser sur l'ignorance des gens pour tirer des conclusions souhaitées est une honte.