Je viens de tenter d'utiliser ce logiciel que l'on va bientot avoir en standard sur les Fedora, ubuntu etc et je dois dire que je suis attere de ce choix. Je le compare avec synaptic et c'est a des annees lumieres niveau utilisabilite et pour trouver de facon simple un logiciel.
Des exemples:
- Par defaut il affiche la description du logiciel et le nom en gris clair illisible en tout petit au dessous.
- Impossibilite de faire une recherche par version de logiciel
- Impossibilite de savoir quels logiciels sont present dans un depot particulier
- impossibilite de savoir l'etat des paquets
- Il refuse de desinstaller un paquet qui rentre en conflit, en l'occurence plasma-widget-networkmanagement en conflit avec networkmanagement-kde.
Naturellement tout cela est present dans le venerable synaptic, je ne comprend absolument pas ce choix. La seule raison que je puisse voir c'est que cela fonctionne avec rpm et deb mais du coup il a fallu prendre le plus petit denominateur commun et cela ce sent enormement.
Voila c'etait le coup de gueule du jour.
Journal packagekit c'est utilisable?
27
juil.
2010
# quelques infos complémentaires
Posté par guepe . Évalué à 4.
Ensuite, y a-t-il des rapports de bugs tels que tu as découverts ? Si non, pourquoi ne pas en faire ?
[^] # Re: quelques infos complémentaires
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# 10 ans
Posté par grid . Évalué à 10.
C'est ça le logiciel libre.
[^] # Re: 10 ans
Posté par BAud (site web personnel) . Évalué à 7.
[^] # Re: 10 ans
Posté par eastwind☯ . Évalué à 5.
[^] # Re: 10 ans
Posté par phil_48 . Évalué à -9.
Ça fait plus de 10 ans que j'ai linux
-> Ah c'est toi qui l'avais ! tu pourrais le rendre s'il te plais
-> Et sinon tu fais quoi avec, tous les six mois tu installes la dernière distribution dont on parle, et ensuite tu retournes sous ton os propriétaire favori ? (Ce n'est qu'une supposition, pas une affirmation),
Tous les 2 à 3 ans :
-> Ça s'est très bien de faire des observations et des statistiques, tu pourrais publier les résultats
ils s'amusent à tout casser et à enlever des fonctionnalités :
-> C'est qui ils ? Des noms, les casseurs doivent être les payeurs.
-> C'est quelles fonctionnalités qu'on a perdu ? Faudrait pas qu'on continue à les utiliser alors qu'elles n'existent plus, ça ferait un peu Tex Avery
C'est ça le logiciel libre.
-> Ah enfin une définition claire concise et sans appel !
-> Ça faisait des années que pas mal de gens essayait, encore ce matin on peut trouver ça :
http://www.mycoop.coop/sinformer/entreprendre-autrement/quan(...)
Mais ce n'est qu'un article parmi des centaines si ce n'est des milliers,
Dommage que dans mon petit tour matinal du net, je n'ai pas lu ton commentaire avant, j'aurais économiser du temps.
Et encore merci pour nous avoir ouvert les yeux !
[^] # Re: 10 ans
Posté par eastwind☯ . Évalué à 4.
[^] # Re: 10 ans
Posté par eastwind☯ . Évalué à 7.
le terminal , ca fait 30 que ca existe , 30 ans en informatique , vaut bien 3 siècles dans la vie réel , , 30 ans que ca reste aussi solide que du rock , :) la ligne de commande est la gardienne de la vrai philosophie unix :)
une seule conclusion ; The Terminal Roxx
# Simplicité
Posté par Johands . Évalué à 7.
//mode les goûts et les couleurs
En fait, je trouve l'interface très "gnomesque" : ergonomie simplifiée réduite au strict minimum vital. On tape le nom de l'application qu'on cherche dans l'unique champ de texte, "recherche" ... les résultats s'affichent, on coche et on appuie sur "valider".
Et jusqu'à présent, ça me suffit amplement. (comprendre "quand y'a un pépin, je repasse en ligne de commande")
///mode
Bref :
Par défaut il affiche la description du logiciel et le nom en gris clair illisible en tout petit au dessous.
Sûrement un problème de thème GTK+2. Aucun souci ici.
Impossible de faire une recherche par version de logiciel
Tu retiens plus facilement les 36 chiffres de versions que le nom de ton application ? Moi non ! Lorsque je cherche un paquet, je rentre son nom, le paquet est ensuite affiché en double, triple, etc. si plusieurs versions sont disponibles. Libre à toi de cocher une version différente pour la ré-installer.
Impossible de savoir quels logiciels sont présents dans un dépôt particulier
Bon oki, ça ne fonctionne pas pour ce cas là.
impossible de savoir l'état des paquets
Euh ... si. L'icône sous Fedora est clairement différent entre les paquets installés ou non. Sans compter la petite case à cocher sur le côté. Il existe même des filtres "n'afficher que les paquets déjà installés", "que les paquets non-installés", ...
Il refuse de dés-installer un paquet qui rentre en conflit, en l'occurrence plasma-widget-networkmanagement en conflit avec networkmanagement-kde.
J'ai parfois le même souci sous aptitude via SSH/ncurse. Certains spinningo-imbroglios de Debian causent des conflits de dépendances à priori insolvables. De la à dire que c'est la faute d'aptitude et non la mienne pour avoir voulu faire mon malin en croisant les dépôts stable / unstable / experimental, il y a un pas que je ne franchirais pas.
[^] # Re: Simplicité
Posté par CrEv (site web personnel) . Évalué à 1.
mais surtout, ça sert à quoi ? c'est fait pour installer des softs, pas se la tripoter avec plein de dépôt et regarder ce qu'il y a sur chaque (ou alors fallait pas l'ajouter le dépôt si c'est pas pour installer ce qu'il y a dessus. Et je pense qu'en outre une fois la recherche de soft effectuée ont doit bien pouvoir choisir lequel on installe non ?)
[^] # Re: Simplicité
Posté par zebra3 . Évalué à 3.
Sous Fedora, qui est aussi tatillonne que Debian sur la notion de libre, ça doit avoir le même but.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Simplicité
Posté par imr . Évalué à 3.
Une vraie question simple, je ne connais pas le soft: comment fait un utilisateur débutant qui ne connait pas les noms des applications?
[^] # Re: Simplicité
Posté par zebra3 . Évalué à 3.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Simplicité
Posté par imr . Évalué à 2.
[^] # Re: Simplicité
Posté par fleny68 . Évalué à 2.
[^] # Re: Simplicité
Posté par GeneralZod . Évalué à 7.
[^] # Re: Simplicité
Posté par Albert_ . Évalué à 3.
j'utilise la version kde donc c'est pas gtk2 mais cela n'enleve rien au fait que en gros et gras tu as la description et en tout petit le nom et pour la version il faut cliquer ou passer au minimum la souris dessus et c'est pas tres pratique lorsque tu as plusieurs versions du meme logiciel.
Tu retiens plus facilement les 36 chiffres de versions que le nom de ton application ? Moi non ! Lorsque je cherche un paquet, je rentre son nom, le paquet est ensuite affiché en double, triple, etc. si plusieurs versions sont disponibles. Libre à toi de cocher une version différente pour la ré-installer.
Des fois comme pour KDE je ne veux pas les versions 3.5 mais 4.4 donc oui c'est pratique ou autre exemple je veux voir quel sont les nouveaux logiciels propose par KDE SC.
Euh ... si. L'icône sous Fedora est clairement différent entre les paquets installés ou non. Sans compter la petite case à cocher sur le côté. Il existe même des filtres "n'afficher que les paquets déjà installés", "que les paquets non-installés", ...
Euh oui mais il y a pas que le blanc et le noir dans la vie il y a aussi les paquets a installe, ou les paquets mal desinstalle ou encore les paquets avec des restes de configuration.
J'ai parfois le même souci sous aptitude via SSH/ncurse. Certains spinningo-imbroglios de Debian causent des conflits de dépendances à priori insolvables.
Sauf que la c'est pas la faute de apt vu que apt-get install a tres bien fonctionne donc le probleme vient de packagekit et point tres con si l'installation echoue il remet a zero la selection effectue c'est genial quand tu as selectionne une dizaine de paquets. Et il n'y a aucun probleme de depots stable/unstable etc je n'ai qu'un seul de selectionne ici.
[^] # Re: Simplicité
Posté par GeneralZod . Évalué à 4.
Le monsieur dit bien qu'on peut distinguer les paquets installés/non-installés dans l'interface
> ou les paquets mal desinstalle
Si t'as un paquet mal désinstallé, soit ton gestionnaire de paquets est sérieusement pété, soit c'est un bogue. Un paquet est installé ou il ne l'est pas, il n'existe pas d'état intermédiaire.
> ou encore les paquets avec des restes de configuration.
C'est une connerie de laisser trainer les fichiers de configuration après la désinstallation mais bon.
Rien ne t'empêche d'implémenter ça dans PK, le système de backends et de capacités est fait pour ça, les backends qui ne supporteront pas cette fonctionnalité ne l'afficheront pas.
> Sauf que la c'est pas la faute de apt vu que apt-get install a tres bien fonctionne
PackageKit ne gère pas les conflits de dépendances, c'est le backend utilisé qui s'en charge, donc ça n'est pas un bogue de PK.
[^] # Re: Simplicité
Posté par Albert_ . Évalué à 1.
Tu as lu ma reponse? Blanc=installe/Noir=non installe et lorsque tu veux savoir les etats intermediaire?
C'est une connerie de laisser trainer les fichiers de configuration après la désinstallation mais bon.
Oui c'est d'ailleurs pour cela que j'aime bien avoir cette option pour les virer. Tout le monde ne peut pas se servir de Fedora...
PackageKit ne gère pas les conflits de dépendances, c'est le backend utilisé qui s'en charge, donc ça n'est pas un bogue de PK.
Je soupconne tout de meme que le backend utilise est apt du coup vu que cela fonctionne en ligne de commande le probleme ne vient pas de apt mais bien de packagekit apres tu peux jouer sur les mots en disant que ce n'est pas packagekit mais le plugin de packagekit qui est mal fait mais cela ne changera pas grand chose au fait que apt fonctionne et pas packagekit.
[^] # Re: Simplicité
Posté par GeneralZod . Évalué à 1.
Les états intermédiaires n'existent pas, soit ton paquet est installé, soit il ne l'est pas, tu ne peux pas avoir de paquet à moitié installé ... La plupart des gestionnaires de paquets ont un fonctionnement transactionnel: pour lui un paquet ne peut avoir que deux états installé ou pas installé.
> Oui c'est d'ailleurs pour cela que j'aime bien avoir cette option pour les virer.
PackageKit est une couche d'abstraction, ce n'est pas un front-end à apt, si le comportement d'apt est stupide par défaut, PK n'y peut pas grand chose.
PK est destiné aux développeurs d'applications qui ont besoin d'une interface générique au système de paquets et aux utilisateurs normaux (qui pour la plupart ne connaissent pas le switch --purge).
D'ailleurs, je ne t'ai pas entendu critiquer le truc de Canonical qui a un comportement similaire à PK à ce niveau-là (pas d'affichage d'états "intermédiaire", pas d'option pour "purger" la configuration) pourtant ça ne gère qu'un seul format de paquet ...
> Je soupconne tout de meme que le backend utilise est apt du coup vu que cela fonctionne en ligne de commande
Le problème que tu décris, c'est lié au résolveur de dépendance or PK ne s'amuse pas à recoder ce genre de chose (qui est souvent lié au format de paquets).
[^] # Re: Simplicité
Posté par zebra3 . Évalué à 2.
Là je ne pige pas : couche d'abstraction et front-end, c'est pas la même chose ?
C'est quoi la différence ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Simplicité
Posté par GeneralZod . Évalué à 2.
Imagine que ton gestionnaire de paquets soit une prise murale et que tu sois un appareil électrique. Le connecteur qui va bien, c'est le frontend mais il ne rentre que dans un seul type de prise murale, l'adaptateur de voyage c'est la couche d'abstraction avec différents embouts (ça c'est le code glue) pour rentrer dans la prise.
[^] # Re: Simplicité
Posté par Thomas Douillard . Évalué à 2.
Une couche d'abstraction, ça n'a rien à voir, en info typiquement c'est une API qui est implémentée pour différents systèmes ayant des fonctionalités similaire, apt - rpm par exemple ... L'API en elle même ne se soucie pas des détails d'implémentation, mais se concentre sur l'accès aux fonctionalités.
Du coup tu peux faire un front-end qui utilise cette API d'abstraction pour avoir une interface capable de piloter différents systèmes de package, ou des meta-fonctionalité que tu n'implémentera qu'une fois pour toute.
[^] # Re: Simplicité
Posté par Albert_ . Évalué à 1.
[^] # Re: Simplicité
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Simplicité
Posté par Marc (site web personnel) . Évalué à 2.
Ah ? Vraiment ? En tout cas, c'est pas le cas avec dpkg, cf les jolis diagrammes:
http://wiki.debian.org/MaintainerScripts
[^] # Re: Simplicité
Posté par GeneralZod . Évalué à 2.
Bref, c'est complétement hors sujet.
[1] http://www.rpm.org/wiki/DevelDocs/StateMachines
[^] # Re: Simplicité
Posté par phoenix (site web personnel) . Évalué à 2.
- installé
- problème de configuration
- non installé
- à moitié installé
[^] # Re: Simplicité
Posté par GeneralZod . Évalué à 0.
> problème de configuration
ça veut rien dire pour le gestionnaire de paquet, comment veux-tu que celui-ci sache que le logiciel est bien configuré ?
> à moitié installé
un gestionnaire de paquet doit s'assurer que l'installation se passe correctement et en cas d'échec que ton système soit dans un état stable donc si tu as un paquet a moitié installé tu as un GROS problème.
Si dpkg permet d'avoir des paquets à moitié installés (ce dont je doute fortement), faudra m'expliquer pour ça crache autant sur RPM ...
[^] # Re: Simplicité
Posté par Albert_ . Évalué à 1.
Tu veux dire que toutes les installations de paquets sous RH se passent les doigts dans le nez et que jamais mais au jgrand jamais cela plante et donc il n'y a rien de prevu pour recuperer une installation qui a crache en plein milieu? En gros meme si en plein milieu de l'installation d'un paquet il n'y a plus d'electricite c'est absolument pas un probleme pour un paquet RPM et tout se terminera proprement?
Puti ca c'est du risk management. Je serai mechant je dirais que RH se la joue mode BP sur le coup!
[^] # Re: Simplicité
Posté par GeneralZod . Évalué à 2.
Si tu as une coupure d'électricité ou un truc du genre, ton gestionnaire de paquet comme ta base de données doit être capable de revenir à un état consistent. RPM comme dpkg te proposent un jeu d'outils pour "réparer" ta base mais ça n'est pas un état normal.
Si tu as un paquet à "moitié installé", c'est que ta base de paquet est corrompue. Quand ça arrive, yum te prévient qu'une transaction n'a pas été achevé correctement et te suggérera de la terminer/nettoyer avant de faire quoique ce soit avant
Si dpkg te présente des paquets à "moitié installé" (ce qui m'étonnerait beaucoup), c'est que t'as eu un souci et tu dois réparer ta base (hint: PackageKit tient compte de la batterie, de son niveau et du réseau utilisé pour te proposer les mises à jour)
[^] # Re: Simplicité
Posté par Albert_ . Évalué à 0.
Si cela arrive d'ou le apt-get -f install pour regler ce genre de probleme par rapport a ton hint il ne faut pas croire qu'il existe que des portables dans la vie.
[^] # Re: Simplicité
Posté par Batchyx . Évalué à 2.
Tu n'a jamais du utiliser Debian toi. Nombre de paquets Debian posent quelques questions à l'utilisateur pour configurer le paquet. Et beaucoup de paquets ont des scripts à lancer après une installation, pour faire des ldconfigs ou mettre à jour des fichiers de confs genre grub.
Et ton gestionnaire de paquet à un moment ou à un autre, il va devoir installer/remplacer/supprimer tes fichiers systèmes par d'autres, et on ne peut pas considérer que nos systèmes de fichiers soient transactionnels. Donc si il y a une coupure de courant, il y a forcement un état intermédiaire, et ton gestionnaire de paquet n'y peut rien.
[^] # Re: Simplicité
Posté par GeneralZod . Évalué à 2.
J'utilise Debian à titre personnel et professionnel (et même ubuntu - à contre-coeur)
> Nombre de paquets Debian posent quelques questions à l'utilisateur pour configurer le paquet.
Je sais. Le problème c'est que t'as des paquets mal foutu (c-a-d qui ne respecte pas les guidelines définis par debian: utiliser debconf judicieusement) et qui empêche une installation silencieuse. L'utilisateur "normal", il pige que dalle aux questions, c'est au distributeur de lui proposer une configuration fonctionnelle (et pourquoi pas quelques variantes), PK permet justement de le faire en début ou fin de transaction.
> Et beaucoup de paquets ont des scripts à lancer après une installation, pour faire des ldconfigs ou mettre à jour des fichiers de confs genre grub.
Les scripts pre/post installation, ça existe dans quasiment tout gestionnaire de paquets.
> il va devoir installer/remplacer/supprimer tes fichiers systèmes par d'autres, et on ne peut pas considérer que nos systèmes de fichiers soient transactionnels
C'est même la principale difficulté pour préserver un état cohérent de ton gestionnaire de paquet
> Donc si il y a une coupure de courant, il y a forcement un état intermédiaire, et ton gestionnaire de paquet n'y peut rien
La seule que tu peux exiger de ton gestionnaire de paquets c'est de pouvoir réparer ce dysfonctionnement (soit en terminant la transaction, soit en l'annulant) mais ça n'est un état intermédiaire mais un état instable/corrompu/dégradé tout ce que tu veux.
Si ce genre de trucs s'accumulent sans réparer ta base de paquets, faut pas t'étonner que ça péte au bout d'un moment.
[^] # Re: Simplicité
Posté par phoenix (site web personnel) . Évalué à 1.
Je prends le premier "Installation" :
- Installed
- Not installed
- Failed config
- Half Installed (Reinstall required)
Donc pour installé, et non installé pas de soucis, je pense que tout le monde est d'accord sur ce que ca veux dire.
Failed config arrive quand le paquet est installé, mais que le paquet n'a pas réussi à mettre à jour sa configuration (pour x raisons, de la faute du mainteneur du paquet, ou non). Le paquet n'est donc pas installé (non utilisable), mais il n'est pas non plus "non installé" car des fichiers sont sur le disque (les fichiers de l'application).
Un simple dpkg --configure -a suffira à reconfigurer le paquet (après correction de ce qui ne va pas)
Pour Half installed, le paquet n'a pas réussi à s'installer dés le début, et les scripts d'annulation de l'installation ont également échoué. Ce cas doit être assez rare mais n'est pas impossible.
Il faudra réinstaller le paquet (ou le supprimer).
La aussi il n'est pas installé, mais il n'est pas non plus "non installé". Il faut que l'utilisateur fasse quelque chose pour qu'il soit dans l'un ou l'autre des états.
Les deux cas sont possible (et pas uniquement dans le cas d'une coupure de courant). Ce sont des cas rares. Souvent même cela empêche d'installer d'autres paquets tant que le problème n'est pas résolu. Mais on est content quand on peut retrouver les paquets qui sont dans un état intermédiaire.
Enfin on a l'état désinstallé, et l'état purger. Purger un programme veux dire qu'on veux également supprimer les fichiers de configuration, alors que désinstaller, ne supprimer pas les fichiers de configuration.
A quoi cela peut servir ? A désinstaller un programme pour installer une version plus récente, ou une application différente mais utilisant les mêmes fichiers de configuration.
Là cela nous fait un état intermédiaire sur la désinstallation.
[^] # Re: Simplicité
Posté par Marc (site web personnel) . Évalué à 1.
vu que ça m'est arrivé plusieurs fois, je dirais pas vraiment que c'est rare... Le plus souvent, c'était simplement par manque de place sur le disque. Dans ce cas, ça plantait un peu n'importe où, souvent dans les scripts pre/post rm. Ca m'est aussi déjà arrivé lors de mise à jour de logiciel dont la conf sur le disque était pas bonne, les scripts, encore une fois, se prenaient les pieds dedans à un moment.
Bref.... Après, si tu abstraits ça à un niveau plus haut, t'as effectivement 2 états: OK, PAS OK. C'est un joli modèle à 2 états, mais que tu as besoin de raffiner en pratique...
[^] # Re: Simplicité
Posté par Albert_ . Évalué à -1.
Ouhais ben moi j'ai l'habitude d'avoir des etats intermediaires comme "tiuent je selectionne ce paquet puis celui la puis celui la, ah merde qu'est ce que j'ai selectionne? Il est pas en doublon ce soft? Voyons voir dans la categorie 'changement en attente'"
Tu comprends mieux ce qu'est un "etat intermediaire" et si tu n'as pas cela sur ton systeme cela me fait peur car tu cliques sur la petites fleches installation et hop aussitot il installe sans attendre si tu as d'autre truc a faire c'est totalement non efficace...
PackageKit est une couche d'abstraction, ce n'est pas un front-end à apt, si le comportement d'apt est stupide par défaut, PK n'y peut pas grand chose.
Synaptic est un front-end a apt et cela marche avec donc si le probleme vient du front-end qu'est packagekit.
D'ailleurs, je ne t'ai pas entendu critiquer le truc de Canonical qui a un comportement similaire à PK à ce niveau-là (pas d'affichage d'états "intermédiaire", pas d'option pour "purger" la configuration) pourtant ça ne gère qu'un seul format de paquet ...
Le truc de canonical c'est packagekit donc je vois pas trop ce que tu racontes a moins que tu parles du app-store (ou un truc comme ca) mais ca existe que sous la version Gnome que je n'utilise pas donc HS.
Le problème que tu décris, c'est lié au résolveur de dépendance or PK ne s'amuse pas à recoder ce genre de chose (qui est souvent lié au format de paquets).
Donc il se sert de apt et c'est amusant comme le frontend synaptic ou aptitude ou apt marche bien dans le cas mentionne et pas packagekit... Ce n'est pas parceque packagekit vient de Fedora que je critique et je te suggere d'installer une debian (vu ton "amour" pour ubuntu je ne pense aps que ce soit le truc a essayer pour toi) et voir comment est foutu synaptic. D'ailleurs je crois meme que tu n'as pas besoin il existe sous Fedora mais il faut s'en servir avec apt et la forcement c'est moins la joie...
[^] # Re: Simplicité
Posté par Thomas Douillard . Évalué à 2.
Dit le mec qui s'est mis dans une position de béotien :p
[^] # Re: Simplicité
Posté par GeneralZod . Évalué à 2.
Tu dis n'importe quoi, ça n'est pas un état intermédiaire pour le gestionnaire de paquets ça, c'est juste la file d'attente. Hint: à gauche, tu as un onglet "Paquets sélectionnés" qui t'affichera les paquets en attente d'installation ou de désinstallation.
C'est pareil avec synaptic, si tu fermes synaptic avant d'avoir démarrer la transaction, tu perds la file d'attente si tu relances celui-ci ou que tu passes par une autre interface !
> Le truc de canonical c'est packagekit donc je vois pas trop ce que tu racontes a moins que tu parles du app-store
Je ne sais pas ce qu'utilise actuellement le machin-store de Canonical (ça n'utilisait pas PK la dernière fois que j'ai zyeuté le code) mais c'est le truc qu'utilise la majorité des ubuntistes et ils s'en plaignent pas plus que cela
> Ce n'est pas parceque packagekit vient de Fedora que je critique
PackageKit est un projet indépendant de Fedora, d'ailleurs le premier backend fonctionnel de PK était celui de conary.
> et je te suggere d'installer une debian (vu ton "amour" pour ubuntu je ne pense aps que ce soit le truc a essayer pour toi)
hint: déjà fait depuis quelques années, on ne critique que ce que l'on connait bien.
[^] # Re: Simplicité
Posté par Albert_ . Évalué à 0.
Ca doit faire longtemps car ubuntu utilise packagekit associe uniquement pour la version gnome un truc au dessus qui s'appelle gnome-app-install ou software-center qui presente les logiciels les plus courrant et c'est tout.
[^] # Re: Simplicité
Posté par Laurent A. . Évalué à 1.
Au fait, tu utilises le front-end GNOME ou KDE pour employer PackageKit ?
[^] # Re: Simplicité
Posté par Albert_ . Évalué à 1.
# PackageKit n'est pas un front-end
Posté par GeneralZod . Évalué à 10.
* ça permet aux application de pouvoir récupérer des greffons (codecs, polices, paquets de langues, pilotes d'impressions, etc ...) sans se soucier du gestionnaire de paquets sous-jacent.
* d'avoir une interface standardisée: tu as des outils en ligne de commande (pkcon), graphiques (gnome-packagekit, kpackagekit, etc ...) pour gérer les paquets, les dépôts, les services packs, mises à jour etc ... Par exemple, PackageKit est capable d'inhiber les mises à jour si tu es sur batterie, de demander un redémarrage ...
* quelques trucs sympa comme avoir un mécanisme standard pour installer les paquets depuis le web, proposer l'installation automatique du paquet correspondant à une commande, etc ... tout ce que chaque distribution réinventait dans son coin.
PK ne se réduit pas au dénominateur commun, t'as un système de backends et chacun précise les actions supportés (gpk-backend-status). Ça n'a pas vocation à remplacer ton gestionnaire de paquets pour les cas d'utilisations avancées. C'est fait pour les utilisateurs "normaux" qui veulent un outil ergonomique pour faire les tâches classiques.
T'aurais pu attendre vendredi, parce que t'as visiblement pas fait l'effort de visiter le site qui a le mérite d'être clair et d'expliquer la démarche.
[^] # Re: PackageKit n'est pas un front-end
Posté par zebra3 . Évalué à 6.
Par exemple, les utilisateurs normaux peuvent avoir le droit de mettre à jour, sans être autorisés à installer ou à supprimer des logiciels.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: PackageKit n'est pas un front-end
Posté par Albert_ . Évalué à 2.
[^] # Re: PackageKit n'est pas un front-end
Posté par Renault (site web personnel) . Évalué à 3.
Ce logiciel n'est pas parfait, de fait il est récent (il a à peine 2 ans dont plus d'un an de boulot pour avoir un bon support de la plupart des gestionnaires de paquets). De plus il n'est que sous Fedora par défaut, Yumex satisfera les plus dégoûtée de PackageKit mais pour ma part je le trouve pour le moment bon.
Le problème c'est comme d'habitude, Ubuntu offre une version en retard et mal intégré, ne rapporte que peu souvent les problèmes qui lui trouvent. Le gars n'est pas un graphiste ni un designer hors pair, si vous avez des recommandations pour l'améliorer, soumettez un bogue et il sera je pense ravis d'avoir de bonnes idées pour améliorer cela.
Cependant je en trouve pas Synaptic comme une référence d'un design clair et efficace, il est certes plus puissant mais je pense qu'une refonte de l'interface serait la bienvenue pour lui aussi (et la logithèque Ubuntu est je pense une réponse à ce problème).
[^] # Re: PackageKit n'est pas un front-end
Posté par eastwind☯ . Évalué à 2.
Ce logiciel n'est pas parfait, de fait il est récent (il a à peine 2 ans dont plus d'un an de boulot pour avoir un bon support de la plupart des gestionnaires de paquets). De plus il n'est que sous Fedora par défaut, Yumex satisfera les plus dégoûtée de PackageKit mais pour ma part je le trouve pour le moment bon."
La question est là , vue les circonstances du logciels , pourqoi se basé sur quelque chose de si récent pour tout changer , et qui plus est maintenue par une seule personne.
Le package manager étant l'une des clés de voutes de l'os et de son interaction homme-machine , pourquoi au vue des conditions s'appuyer aussi fortement sur un logiciel qui me semble n'a pas encore fait ses preuves (vue le role central de cette catégorie de programme )
Cela va à l'encontre du bon sens , de la philosophie unix et de celle de debian ( ha oui c'est pour fedora ,seulement , mais bon cela ne change pas la question de fond )
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . Évalué à 3.
PackageKit ne remplace pas ton gestionnaire de paquets, il offre une couche d'abstraction.
Par exemple, quand tu lances une vidéo avec totem, si le codec n'est pas installé Totem fait une requête à PK qui s'occupe de l'installer sans se soucier du gestionnaire de paquet utilisé.
Auparavant, t'avais autant de scripts helpers que de distribution (si ce n'est plus !) pour gérer ce genre de chose.
> La question est là , vue les circonstances du logciels , pourqoi se basé sur quelque chose de si récent pour tout changer , et qui plus est maintenue par une seule personne.
PK a un mainteneur et plusieurs développeurs, la difficulté c'est plutôt dans le support des backends qui demande de bien connaitre le gestionnaire de paquet en question.
Le truc, c'est que quand le mainteneur a demandé de l'aide pour écrire les backends, il a trouvé facilement des gens motivés pour le faire sauf pour debian/ubuntu pour qui PERSONNE ne s'était porté volontaire. il a fallu attendre genre deux ans pour que les mecs se réveillent.
> pourquoi au vue des conditions s'appuyer aussi fortement sur un logiciel qui me semble n'a pas encore fait ses preuves
PK a fait ses preuves, gpk-application est l'interface graphique par défaut de Fedora, Foresight Linux (avant même Fedora) et dans certains cas d'Ubuntu (la mise à jour entre autre) ... La quasi-totalité des distributions basés sur GNOME l'utilisent depuis plus d'un an.
> Cela va à l'encontre du bon sens , de la philosophie unix et de celle de debian
Si t'écoute les conneries d'albert_ qui n'a même pas visité le site ou même utilisé plus de 30s le bouzin, forcément oui.
[^] # Re: PackageKit n'est pas un front-end
Posté par Albert_ . Évalué à 0.
Ah donc tu es en train de dire que pour utiliser packagekit il faut lire un bouquin voir passer un diplome specifique? Et moi qui croyais que Linux se democratisait et se simplifier...
Tiens quand a parler d'un autre systeme bien mieux foutu je te nommerais pisi celui de pardus mais la encore c'est pas du Fedora donc ca doit etre le mal incarne.
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . Évalué à 2.
Avant de critiquer, faudrait peut-être l'avoir utilisé et avant de poster un journal sur l'utilité de PackageKit, avoir visiter le site pour comprendre le pourquoi du comment.
Tu parles d'états "intermédiaires" de paquets qui n'existent que dans ton obscure cervelle, tu t'obstines à chier sur l'inexistant "résolveur de dépendance" de PK alors que c'est visiblement soit un bogue dans apt soit un bogue situé entre la chaise et le clavier, etc ...
Tu critiques PK sur des cas d'utilisations spécifiques (genre purger la configuration) alors que c'est principalement destiné au grand public qui en a rien à branler. L'utilisateur avancé, il utilisera directement l'outil sous-jacent (apt*/yum/conary/urpmi/portage etc ...)
> Tiens quand a parler d'un autre systeme bien mieux foutu je te nommerais pisi celui de pardus
Quel est le rapport entre pisi et PackageKit ? pisi c'est un gestionnaire de paquets comme RPM ou dpkg (et qui intégre des fonctionnalités des surcouches types yum/apt etc ...) Au passage, PackageKit possède un backend pisi.
> mais la encore c'est pas du Fedora donc ca doit etre le mal incarne
Tiens, m'attribuer des mots que je n'ai jamais prononcé voire jamais pensé, ça va très certainement t'éviter le ridicule. Tu t'enfonces, Charles !
[^] # Re: PackageKit n'est pas un front-end
Posté par Albert_ . Évalué à 1.
http://www.packagekit.org/pk-users.html
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . Évalué à 2.
http://www.packagekit.org/pk-authors.html ==> le mainteneur du backend pisi est aussi un des développeurs de pisi ....
[^] # Re: PackageKit n'est pas un front-end
Posté par Albert_ . Évalué à 1.
[^] # Re: PackageKit n'est pas un front-end
Posté par Albert_ . Évalué à 0.
Si mes souvenirs sont bons il existait avant packagekit un truc s'appelant synaptic (tiens curieux j'en ai parle auparavant) et apt qui fonctionne avec les rpm ET les deb mais bon ca vient du monde debian donc c'est pas bien et on va reinventer la roue from scratch et apres on s'etonne que debian se foutait completement de se mettre dans le truc...
Le truc ridicule c'est que ubuntu se soit base sur ce truc mais bon nous ne sommes plus a une incoherence de leur part, n'est ce pas?
Pour que packagekit soit vraiment ce qu'il est cense etre il faut donc que:
1 - le backend apt soit ameliore
2 - les backend tar.gz (pour slack), pisi pour pardus et je ne sais pas quoi pour les autre distribs soit implemente
3 - ameliore grandement les front-ends qui sont les memes pour KDE et Gnome (encore une volonte d'harmonisation mal venu) et passablement mal foutu.
Et ben il en reste du boulot!
[^] # Re: PackageKit n'est pas un front-end
Posté par zebra3 . Évalué à 2.
Va lire http://wiki.debian.org/PackageKit et http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468132 , tu comprendras pourquoi il n'y a pas grand chose de fait, et en quoi ce n'est pas la faute de Debian/Ubuntu.
Ce n'est pas dû au fait que personne ne s'est porté volontaire, mais parce que la vision de PackageKit ne correspond pas à APT/DPKG.
Notamment, le développeur de PackageKit a décrété qu'il ne devait pas y avoir d'interaction entre le gestionnaire de paquet et l'utilisateur pendant une transaction; or APT l'autorise et en fait usage avec abondance.
Par exemple, installe KDM et GDM ensemble, et APT te demandera lequel tu préfères utiliser. Autre exemple, installe la JVM de Sun et APT te demande d'accepter la licence.
Tant que cette divergence d'opinion ne sera pas résolue, aucune chance de le voir arriver dans Debian.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . Évalué à 4.
C'est pourtant ce qu'il s'est passé. Il a fallu attendre près de deux ans avant que des gens de debian/ubuntu s'investissent dans le projet.
> mais parce que la vision de PackageKit ne correspond pas à APT/DPKG.
Pas tout à fait, les packaging guidelines de Debian exigent de passer par debconf or t'as plein de paquets qui passent par stdin ce qui n'est pas gérable.
Le problème, c'est que si le processus exige une interaction utilisateur, tu ne peux plus faire de mises à jours automatique, c'est plus chiant pour gérer l'installation de greffons à un programme.
PackageKit permet dans une certaine mesure les interactions utilisateurs mais seulement au début ou à la fin d'une transaction (ce qui est logique).
C'est facile de rejeter la faute sur le mainteneur mais quand il a ouvert la discussion sur le design de PK, on n'a pas beaucoup vu des gens de Debian. Et comme par hasard, PK gère environ 15 backends différents et le seul qui pose problème c'est apt ...
[^] # Re: PackageKit n'est pas un front-end
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
J'ai beau retourner la phrase dans tous les sens, tout ce que j'arrive à en tirer c'est que tu veux qu'on ne se rende pas compte qu'il y ait des mises-à-jour. Oh, mon GIMP a changé tout seul sans que je comprenne pourquoi...
Déjà que quand tu installes un logiciel, ça t'affiche bien en gros ce que ça fait. Mais pour trouver le nom du logiciel, tu peux te brosser, tu n'as droit qu'au nom du paquet, et quand j'ai demandé empathy j'ai vu deux versions au numéro quasi proche, madame Michu choisit lequel ? Ben comme elle voit plein de paquets avec empathy dans leur nom et des mentions bizarres de amd64 ou trucs du genre et des numéros alambiquées, hop on sélectionne tout au pif sans savoir ce qu'on fait et on verra bien après. Ou alors on fait comme sous Windows et OS X où les choses sont simples, on télécharge sur le site du programme et puis voilà. Je croyais qu'on cherchait à éviter cette situation...
En fait avec packagekit tu ne sais pas ce que tu installes, tu ne vois pas les mises à jour, c'est l'aveuglette.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . Évalué à 2.
L'utilisateur normal, il ne comprends pas les questions qu'on lui pose, il veut juste un système qui marche point barre. Moins il a de configuration à faire, mieux il se portera.
Je rappelle qu'à la base, Debian c'est le système d'exploitation universel qui cherche à recouvrir un maximum de cas, choisir finement la configuration pour chaque paquet c'est pertinent, ça l'est beaucoup moins pour le grand public (d'où le succès d'Ubuntu qui à l'origine était une Debian avec une configuration par défaut adapté au grand public).
> Oh, mon GIMP a changé tout seul sans que je comprenne pourquoi.
Un système de mise à jour doit te prévenir qu'il a des mises à jour à faire, te présenter le détails si tu es curieux, mais si tu veux juste faire les mises à jours de sécurité, il n'a pas à te faire chier.
> Quand j'ai demandé empathy j'ai vu deux versions au numéro quasi proche, madame Michu choisit lequel
c'est au distributeur de gérer ça, c'est stupide de proposer deux versions du même programme utilisateur à l'utilisateur de base.
> Ou alors on fait comme sous Windows et OS X où les choses sont simples, on télécharge sur le site du programme et puis voilà. Je croyais qu'on cherchait à éviter cette situation.
Justement, tu dois simplifier le processus, sinon c'est trop compliqué et l'utilisateur fera comme avant, il essaiera de récupérer un binaire et de le foutre quelque part.
> En fait avec packagekit tu ne sais pas ce que tu installes, tu ne vois pas les mises à jour, c'est l'aveuglette.
Où tu as vu que c'était à l'aveuglette ? Quand tu fais une mise à jour, PK te propose de voir le contenu (avec même une jolie explication du pourquoi de la maj), de filtrer celles-ci et te notifient de leur fin. Tu veux les maj automatique, tu peux.
T'as au moins essayé avant de juger à l'emporte pièce ?
[^] # Re: PackageKit n'est pas un front-end
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
>c'est au distributeur de gérer ça, c'est stupide de proposer deux versions du même programme utilisateur à l'utilisateur de base.
Packagekit le fait, pas Synaptic. Tu veux une capture ?
http://s2.noelshack.com/uploads/images/7576350619167_pkvssyn(...)
J'invente rien : packagekit montre tout en double, cache le nom du logiciel et privilégie le nom du paquet, et si on veut une petite différence user-friendly on peut télécharger une capture d'écran pour en avoir un aperçu via synaptic. Et pk qui veut être facile d'utilisation il propose quoi ? Il propose de montrer tout ce qu'il veut bien montrer mais pas tout ce qu'on pourrait vouloir sur ledit logiciel, c'est sûr que c'est d'une importance capitale de savoir la place prise par un logiciel, et comme il y a des infos dont on se contrefout (les dépendances, les paquets suggérés, ) on bannit la possibilité de les visualiser.
>Justement, tu dois simplifier le processus, sinon c'est trop compliqué et l'utilisateur fera comme avant, il essaiera de récupérer un binaire et de le foutre quelque part.
C'est bien le problème !
Sous fedora j'ai essayé de les mettre ces plugins ugly pour gstreamer afin de lire mes contenus. L'installation automatique des plugins (sûrement comme tu dis packagekit) ne les trouve pas. D'accord, je dois ajouter le dépôt RPM Fusion libre. Toujours rien. J'ajoute le dépôt RPM Fusion non-libre. Toujours pas. La faute repose sur qui, sur fedora ou packagekit ?
Mais pour éviter que tout soit la faute de Fedora, il y a deux captures d'écran sur Ubuntu qui peuvent appuyer que c'est pas facile à gérer comme programme.
>Quand tu fais une mise à jour, PK te propose de voir le contenu (avec même une jolie explication du pourquoi de la maj), de filtrer celles-ci et te notifient de leur fin.
Je viens de mettre côte-à-côte la mise à jour selon Synaptic et selon Packagekit :
http://s2.noelshack.com/uploads/images/12674498313411_pkvssy(...)
Les différences ? Sous PK on voit en gros la description du paquet, ensuite on voit le nom du paquet, et on voit une description de la mise à jour effectuée (c'est subjectif mais la description est moche sous PK). Sous Synaptic, on voit le nom du logiciel mis à jour, la description du paquet, on a ensuite accès si on est curieux au détail qui est la description des mises à jour et aussi une description complète de ce que ça fait.
Ah oui, il y a un filtre : c'est une maj de sécurité ou pas. Ça concerne vachement l'utilisateur lambda de faire une maj de sécurité et va faire très attention à la faire au lieu de la maj de gimp...
>L'utilisateur normal, il ne comprends pas les questions qu'on lui pose,
> il veut juste un système qui marche point barre.
>Moins il a de configuration à faire, mieux il se portera.
Correction : moins il a de questions à se poser, mieux il se portera. Ah tiens, ça veut dire quoi, "An MSN messenger written in Tcl" ? Ce serait pas plus facile de dire amsn directement ? Et voir l'exemple d'empathy pour se poser des questions quand ce n'est pas nécessaire.
Le software center est largement au-dessus de Packagekit en terme de visibilité :
http://s2.noelshack.com/uploads/images/12753149037552_uscvsp(...)
Et on peut utiliser soit le software center pour faire simple soit synaptic pour être plus technique. Mais packagekit, on le place où ? L'utilisateur lambda comprend-t-il ce qu'il installe ? Peut-on apprendre des détails plus techniques sur ce qu'on installe ? Non et non.
Le seul avantage de Packagekit est de botter les fesses de tous ces outils pour manipuler les rpm et que personne n'arrive à se mettre d'accord. Ben oui, rpm les gens trouvent ça bien mais pas si c'est implémenté par mon voisin et il faut que je refasse tout moi-même. Par contre du côté de apt les trolls sont trop calmes et on s'amuse parfois à traiter de dinosaure les utilisateurs d'aptitude, les distributions dotées de .deb se rangent derrière les mêmes outils, ce qui jusque là est impossible chez les rpm. Oh tiens, on utilise même les outils de Debian pour gérer les rpm :
http://fr.wikipedia.org/wiki/RPM_Package_Manager
Packagekit ne comble aucun besoin du côté des .deb, et n'est pas plus simple d'utilisation du tout. Après ma dernière expérience avec Yumex c'était juste avant de trouver qu'Ubuntu proposait quelque chose de bien plus confortable…
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . Évalué à 2.
Par défaut, le filtre "seulement les paquets les plus récents" est activé, soit tu l'as désactivé, soit le packager l'a fait à ta place (enfin, on l'habitude des packagers d'ubuntu qui font le boulot à moitié)
> si on veut une petite différence user-friendly on peut télécharger une capture d'écran pour en avoir un aperçu via synaptic
Synaptic existe depuis 5 fois plus longtemps que PK et n'a pas à gérer 15 backends.
> Il propose de montrer tout ce qu'il veut bien montrer mais pas tout ce qu'on pourrait vouloir sur ledit logiciel, c'est sûr que c'est d'une importance capitale de savoir la place prise par un logiciel, et comme il y a des infos dont on se contrefout (les dépendances, les paquets suggérés, ) on bannit la possibilité de les visualiser.
Si tu veux voir les dépendances, les suggestions, la place, tu n'es plus un utilisateur de base
> Sous fedora j'ai essayé de les mettre ces plugins ugly pour gstreamer afin de lire mes contenus.
Chez moi et chez beaucoup d'autre ça marche (si on installe rpmfusion certes).
Faudrait arrêter de FUD-er, parce que j'ai pas vu passer de tickets à ce sujet sur le bugzilla ou des discussions sur les forums ou chan irc.
> Mais packagekit, on le place où ? L'utilisateur lambda comprend-t-il ce qu'il installe ? Peut-on apprendre des détails plus techniques sur ce qu'on installe ? Non et non.
T'es aveugle ou quoi ? c'est en bas.
> Ah tiens, ça veut dire quoi, "An MSN messenger written in Tcl" ?
T'es ridicule, synaptic comme PK récupére les chaines de caractères qu'on lui donne. Rapporte le bogue au lieu de délirer.
> Le seul avantage de Packagekit est de botter les fesses de tous ces outils pour manipuler les rpm et que personne n'arrive à se mettre d'accord.
Mais bien sûr, c'est pour ça que le premier backend complété c'était pas yum ni urpmi ou zypp ...
> les distributions dotées de .deb se rangent derrière les mêmes outils, ce qui jusque là est impossible chez les rpm
La différence c'est qu'il n'existe qu'une distribution utilisant dpkg, les autres sont des dérivées.
Si je te dis que toutes les distributions basés sur Fedora se rangent derrière les mêmes outils, tu vas penser quoi ?
> Packagekit ne comble aucun besoin du côté des .deb, et n'est pas plus simple d'utilisation du tout
Que ton lecteur multimédia puisse télécharger tranquillou les codecs qui lui manque (c'est genre utiliser depuis au moins 1 an dans ubuntu quoi), que ton gestionnaire d'impression puisse récupérer les pilotes, etc.. Même si tu n'utilises pas l'interface de gestion de paquets, tu utilises PK depuis un bon bout de temps et il te facilite bien la vie.
Certaines de tes critiques sont justes (les interfaces graphiques de PK sont améliorables mais c'est loin d'être figé dans PK), d'autres sont déplacés (tu reproches des problèmes liés au packaging comme les chaines ou des options mal configurés), et d'autres sont hors-sujet (comme afficher des infos qui n'intéressent pas la cible), tes conneries sur RPM/dpkg, etc ...
[^] # Re: PackageKit n'est pas un front-end
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Cool, Fedora désactive ce filtre qui n'est pas accessible dans les menus ! Plus besoin de troller sur Ubuntu pour sauver l'honneur de Packagekit !
>Si tu veux voir les dépendances, les suggestions, la place, tu n'es plus un utilisateur de base
Et pourtant la place, c'est ce qui est montré en bas à droite.
Ah d'ailleurs :
>> Mais packagekit, on le place où ? L'utilisateur lambda comprend-t-il ce qu'il installe ? Peut-on apprendre des détails plus techniques sur ce qu'on installe ? Non et non.
>T'es aveugle ou quoi ? c'est en bas.
En bas t'as trois grammes d'information, youhou ! C'est de la pacotille face à ce que propose Synaptic comme détails techniques.
>> Ah tiens, ça veut dire quoi, "An MSN messenger written in Tcl" ?
>T'es ridicule, synaptic comme PK récupére les chaines de caractères qu'on lui donne.
>Rapporte le bogue au lieu de délirer.
Le problème c'est la mise en avant : l'un montre amsn et explique que c'est "an msn blablabla", l'autre montre un paquet qui est "an msn blablabla". Je crois pas que ça relève du bogue mais de la wishlist que de voir le véritable nom du logiciel.
Les débianistes ne sont pas intéressés par Packagekit (ah pardon utiliser packagekit en lieu et place de Synaptic) et ça a été dit moultes fois dans ce journal (à commencer par l'auteur lui-même). Je ne crois pas qu'on puisse forcer à contribuer des gens qui n'en ont pas envie, et ça risque d'en rester là.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: PackageKit n'est pas un front-end
Posté par phoenix (site web personnel) . Évalué à 1.
Par contre cela à la condition d'avoir une interface adapté en fonction des possibilités du système de paquet. Vu la simplicité de PackageKit, je ne m'en servirai pas pour le moment (et préfère aptitude). Mais le jour où il sera mur, pourquoi pas.
Ce qui veulent continuer autre chose pourront toujours continuer. Les autres auront une interface homogène suivant les distribution, avec une application KDE et la présentation d'une application KDE pour ceux qui préfère, et une application GNOME avec la simplicité que cela implique pour ceux qui préfère avoir un minimum d'option.
Je pense que c'est une des briques qui permettra de rendre XXX/Linux plus homogène, sans pour autant supprimer ce qui fait la diversité des distributions.
[^] # Re: PackageKit n'est pas un front-end
Posté par zebra3 . Évalué à 2.
C'est le comportement de Yum et ça s'explique par le fait que deux versions différentes d'un paquet peuvent être installées.
Je pense que PK l'a récupéré car son premier backend fut celui de Yum, et il n'a pas été adapté complètement pour APT par Canonical.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . Évalué à 2.
C'est aussi le comportement d'apt, après synaptic doit taper dans les méta-données mais faut modifier le backend en conséquence comme tu le soulignes plus bas.
> Je pense que PK l'a récupéré car son premier backend fut celui de Yum,
Le premier backend c'est conary, c'était même le gestionnaire de paquets graphique par défaut de Foresight Linux avant même qu'on ait un backend yum fonctionnel.
[^] # Re: PackageKit n'est pas un front-end
Posté par zebra3 . Évalué à 2.
Sinon je ne connais pas Conary ni ses spécificités. J'étais persuadé que la première distribution à intégrer PK était Fedora (et en même temps, c'est un peu son rôle).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: PackageKit n'est pas un front-end
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Si bien sûr il n'y a pas qu'une seule version de proposée.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: PackageKit n'est pas un front-end
Posté par zebra3 . Évalué à 3.
Alors qu'avec Yum, on peut installer simultanément deux versions d'un paquet. C'est surtout utile pour le noyau, quand tu en installes un nouveau mais que tu veux garder l'ancien qui marche : le paquet se nomme dans les deux cas « kernel ».
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: PackageKit n'est pas un front-end
Posté par Albert_ . Évalué à 2.
L'uniformisation pas le bas c'est vraiment dommage tout de meme.
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . Évalué à 4.
ça a surtout révélé des pratiques pas très nets dans le packaging debian. Il n'est pas normal qu'on ne puisse pas réaliser une installation silencieuse de paquets et que chaque paquet réinvente une façon d'interagir avec l'utilisateur. J'installe 100 paquets, est-ce que je dois intervenir à chaque fois ?
[^] # Re: PackageKit n'est pas un front-end
Posté par Albert_ . Évalué à 1.
Qu'il n'y ait qu'une seule personne developpant ce logiciel c'est pas de bol mais pas trop mon probleme. Je trouve dommage que le systeme de management des paquets qui est en train de s'uniformiser autour de cette solution soit aussi peu clair et pratique et je suis sur que cela va attirer tout plein d'utilisateur et pas du tout les degouttes...
Je comprend mieux du coup la raison du "app-store" de ubuntu et je m'inquiete que pour des raisons de boutiques (Fedora versus ubuntu) les personnes pouvant avoir un impact sur le developement (d'autre contrib de Fedora) soit aussi borne sur le sujet et considere ce soft comme parfait et sans defaut.
En ce qui concerne remonte les bugs ca fait quelques temps que je ne fais plus cela que ce soit pour les projets ubuntu ou Fedora car cela ne sert a rien au vu de mon experience. Je prefere remonter directement a KDE ou la cela fonctionne bien, les bugs ne tombent pas oux oubliettes et les devs acceptent la critique.
[^] # Re: PackageKit n'est pas un front-end
Posté par Renault (site web personnel) . Évalué à 1.
Puis là ce n'est même pas Fedora qui le développe, c'est un mec indépendant, le même qui a fait gnome-color-manager d'ailleurs. Et il accepte la critique, j'ai déjà rapporté des soucis dans la vitesse de certaines actions, il en a tenu compte et il y a eu quelques progrès à certaines étapes là dessus.
Ce qui est con, et chiant, c'est que Ubuntu a fait son truc à part alors que PackageKit était là depuis un moment. Certes il n'est pas parfait mais c'était une base intéressante pour l'améliorer et que tout le monde profite de leur travail. Là globalement leur logithèque ne va que les concerner voire les distributions à base de Debian. C'est dommage, car là on avait un outil qui permettait d'avoir quelque chose d'assez universel (là où pas mal de gens se plaignent de la diversité des IHM de ces logiciels) et de correct, car je suis sûr que Richard Hugues aurait bien accepté leur contribution dans l'interface qui est perfectible.
[^] # Re: PackageKit n'est pas un front-end
Posté par eastwind☯ . Évalué à 2.
C'est du logiciel libre , donc suffit de reprendre les sources et d'inclure là ou tu veux .
Ensuite que la distro accepte ou pas , c'est une question de politique de la distribution et de la communauté j.
Au pire tu fait le bousin à la main , au mieux tu le trouve déjà fait dans un dépot tiers .
From this point of view the only problem was a political one .
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.