Cher Journal,
aujourd'hui vendredi, jour propice à la discussion, quelques idées et frustrations me trottaient dans la tête.
Jusqu'à présent j'étais plutôt habitué à l'utilisation de Debian, et sans remettre en cause ceci j'ai commencé à tester d'autres distributions. C'est alors que j'ai remarqué que ce qui me semblait normal sous Debian ne l'était pas forcément ailleurs, par exemple certains programmes se retrouvent dans /usr/bin sous debian, alors qu'ailleurs ils sont installés par défaut dans /usr/local/bin, de même on peut avoir des applications graphiques dans /usr/bin, et ailleurs on les retrouve dans /usr/X11R6/bin, voire dans /opt etc. Sans vouloir défendre plus un point de vue qu'un autre, pour parler franchement est-ce qu'il n'est pas débile de faire un format de paquet par distribution, les paquets d'une distribution à l'autre ne s'échangeant pas forcément très bien ? (dépendances etc.)
Si j'ai bien compris le format .deb est arrivé le premier (cf. wikipedia à propos du Linux Standard Base), puis .rpm, mais d'une distribution à l'autre, les rpm ne sont pas forcément compatibles. Donc on a des rpm spécifiques à red had, fedora, d'autres à mandriva, opensuse, des deb spécifiques à debian, d'autres à ubuntu (pourquoi n'ont-ils pas sorti des .ubu à la place ?), et puis des tgz pour slackware, et si on peut convertir de l'un à l'autre avec la commande alien (de deb à rpm et vice versa), d'une distribution rpm à l'autre c'est plutôt hasardeux, pour ce que j'ai vu (et idem de debian à ubuntu)
J'ai trouvé aussi qu'il existait un genre de consortium Filesystem Hierarchy Standard, mais que cela n'avait pas été respecté non plus.
Il en va de même pour les fichiers de configuration, et tout cela contribue à faire un joyeu bordel pour qui veut s'y retrouver un peu. Alors on va dire que c'est la diversité qui fait la force du libre, mais je trouve dommage (j'ai écrit "débile" plus haut) que les efforts des empaqueteurs soient dispersé à cause de cela. Si quelqu'un passe (qui a dit perd ?) du temps à empaqueter pour Debian, son travail ne sera pas utile pour ceux qui utilisent opensuse ou fedora, etc. Même s'il existe des outils comme smart install, ce n'est pas la panacée non plus, et le système linux me semble un peu affaibli par cet éclatement.
Alors parfois les acteurs des solutions Unix arrivent à s'entendre pour avancer (comme ils avaient pu faire pour les systèmes de fichier, cf. http://linuxfr.org/2006/07/23/21124.html ), est-ce qu'ils ne pourraient pas faire de même pour la hiérarchie unix, le format de packetage, et les fichiers de configuration (virez-moi ces fichiers avec des . du dossier /home svp, c'est une horreur sans nom car tous les programmes ne les filtrent pas)
Bien sûr les avis de chacun divergent, mais ne serait-il pas possible dans un premier temps d'envisager de faire tout un système "propre", et que les spécificités actuelles des diverses distributions se retrouvent via des liens symboliques ? (un peu comme dans gobolinux)
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
http://fr.wikipedia.org/wiki/Linux_Standard_Base
Enfin, et on pourrait en faire tout un nouveau journal, au niveau de la distribution des binaires, cela ne serait pas mal s'il y avait également un peu de standardisation. Je dois dire qu'avant je n'appréciais pas trop un système comme autopacketage, mais finalement ce n'est pas si mal, car cela permet de s'installer sur la plupart des distributions (on en revient au problème que si tout était un peu moins bordélique dans les systèmes de paquets, il n'y aurait pas besoin de système comme autopacketage... car je ne suis pas trop en faveur de binaires à télécharger et installer façon windows ou pcbsd). D'ailleurs cela serait bien si cette distribution de binaire pourrait être un peu plus généralisée par les auteurs de logiciels, sans remettre en cause la présence des sources bien entendu, c'est vraiment lourd lorsque l'on se trouve avec un petit programme à compiler qui repose sur des environnements de programmation pas très léger genre gtk, sdl, qt, clanlib etc. Pour quelqu'un qui connait un peu ça va, pour un autre, il va découvrir la joie de la recherche des fichiers de dev, des configure qui ne passent pas (pourquoi c'est pas les grosses bibliothèques à problème qui sont testées en premier d'ailleurs, cela éviterait de tout lister pour rien ?), des make qui flanchent, et surtout du jeu de ricochet des dépendances de dépendances de dépendances...
L'autre fois pour compiler un truc "tout bête" comme ion3 sous opensuse j'ai dû mettre 1/2 heure, chaque dépendance dépendait d'une autre qui au final ne compilait pas, et j'en ai été quitte pour installer ion2 à la place...
En fait sur pas mal de projets on trouve 1 binaire windows, 1 paquet dmg binaire mac osx, et les sources pour linux (démerdez-vous, et tant pis pour les newbies). Et si on n'a pas les sources, c'est un paquet pour debian, un pour ubuntu, un pour fedora, un pour mandriva, un pour suse, un pour slackware... (cf. http://www.videolan.org/vlc/ )
C'est vraiment pas pour aider le décideur pressé tout ça...
Journal Distributions Linux, vers un éclatement des formats de paquetages ?
27
oct.
2006
# La solution ...
Posté par alexissoft . Évalué à 1.
http://autopackage.org/
[^] # Re: La solution ? Pas vraiment...
Posté par liberforce (site web personnel) . Évalué à 4.
http://autopackage.org/faq.html
Donc non, autopackage n'est pas la solution.
[^] # Re: La solution ? Pas vraiment...
Posté par Bruno Coudoin (site web personnel) . Évalué à 6.
Le problème et les besoins sont très variés, il n'y a pas de solution unique. En tous les cas, le système de packaging des distros à montré ses qualités mais aussi ses limites et il est temps que les projets fournissent des binaires cross / distro installable par des non informaticiens. D'après moi, sans cela, GNU/Linux ne pourra pas progresser sur le desktop grand public.
[^] # Re: La solution ? Pas vraiment...
Posté par RB . Évalué à 3.
Le système de package sous linux et la manière d'installer des applications (et de mettre à jour TOUT le système) est probablement ce qui impressionne le plus ceux qui ne connaissent pas Linux et est une des principales qualité du système. Evidemment, ce serait mieux qu'un seul système, parfait, émmerge.
Ce que je trouve le plus étonnant à ce sujet c'est comment, après toutes ces années (de packages) des grosses distros comme opensuse arrivent à sortir des systèmes pourris (lors de la release)
L'autre chose qui m'étonne c'est à quel point, un système de package qui me semblait assez vieillot, apt/dpkg, est rapide et fonctionne bien. Je trouve les système à base d'RPM plus lent, et sur gentoo, même avec des paquets binaires, emerge est lamentablement lent.
Bon en attendant, en utilisant debian/ubuntu on a accès à, je pense, plus de 95% de tous ce qui existe sous linux en package.
[^] # Re: La solution ? Pas vraiment...
Posté par Olivier Serve (site web personnel) . Évalué à 4.
Et ça, aucun autre gestionnaire de paquets n'est capable de le faire.
[^] # Re: La solution ? Pas vraiment...
Posté par thermos . Évalué à 2.
[^] # Re: La solution ? Pas vraiment...
Posté par Bapt (site web personnel) . Évalué à 3.
[^] # Re: La solution ? Pas vraiment...
Posté par Bruno Coudoin (site web personnel) . Évalué à 4.
Pour le cas de GCompris, seules quelques distributions mettent à jour régulièrement et rapidement. Pour les autres, c'est au coup par coup en fonction de la disponibilité d'un packageur.
Mais attention, il y a très peut de backport, c'est à dire que pour utiliser la dernière version de GCompris, les utilisateurs doivent aussi utiliser la dernière version de leur distribution. Pour nous ce n'est pas un problème mais les utilisateurs non geek non ni l'envie, ni les conpétences pour mettre à jour leur distro et résoudre tous les petits problème qui peuvent arriver.
C'est pour cela qu'une version étendue aux librairies graphique du LSB est une nécssité. Ainsi les développeurs pourrait cibler une version du LSB plutot que les librairies installés dans leur distro au moment du développement.
L'autre problème important c'est les version BETA des projets qui ne sont pas packagé. Ce qui signifie que seul les développeurs, ceux qui savent compiler peuvent tester les logiciels. C'est vraiment pas terrible. Dans mon cas, les utilisateurs sont des professeurs, heuresement certains ont cette compétence et peuvent remonter les problèmes. Pour aller plus loin sur le poste client, il est indispensable que n'importe qui puisse installer n'importe quelle version d'un logiciel, BETA ou pas.
[^] # Re: La solution ? Pas vraiment...
Posté par Ph Husson (site web personnel) . Évalué à 3.
[^] # Re: Une solution ... AUTOPACKAGE
Posté par JP Martin . Évalué à 2.
J'avais fait un post en janvier dernier en ce sens !
http://www.linuxfr.org/comments/666470,1.html
Ce que je trouve intolérable et pas du tout productif, c'est d'avoir aujourd'hui, un super jeu (Frozen-Bubble 2) qui vient de sortir et de devoir le compiler car les binaire ne sont que pour mandriva et non pas pour debian, fedora et opensuse (ma distribution).
Lorsqu'il y aura des binaires pour windows, ça sera pour toutes les versions... Alors si vous trouvez ça normal, Linux ne pourra pas s'implanter auprès d'un large public car trop compliqué !
Dans ce cas précis où le jeu n'a rien à voir avec le système, je pense que AutoPackage est une très très bonne solution. Certes, une centralisation des logiciels installés sur le système doit être possible (rpm et autopackage) afin d'assurer la maintenance. Une idée serait d'avoir une notification lorsque le logiciel est disponible en version rpm afin d'assurer un passage autopackage->rpm
Bref, il y a des progrès à faire afin de disposer de logiciels qui viennent juste de sortir parce que sous windows, c'est vraiment plus simple...
JP Martin sous OpenSuSE 10.1/kde3.5.1
NB : super le correcteur orthographique sous firefox 2
[^] # Re: Une solution ... AUTOPACKAGE
Posté par Gniarf . Évalué à 3.
mais mais mais...
tu veux bien attendre 5 MINUTES que quelqu'un fasse le sale boulot à ta place, que ça soit l'auteur du soft, le(s) packageur(s) de ta distribution, des tiers qui font des rpm ou autres .deb dans leur coin pour ta distrib à toi, ou encore une organisation à la Klik ou Autopackage...
parce que même si ces derniers finissent par devenir d'usage répandu, si personne n'a encore fait de paquet pour eux, il te faudra toujours attendre que quelqu'un le fasse, ou le faire toi-même.
ah, tu vas me dire, ça serait plutôt à l'auteur de le faire ? comme ça il n'aurait qu'une seule cible à générer au lieu de 5 ou plus ?
en effet c'est une possibilité, il se trouve juste qu'ils ont déjà souvent beaucoup de boulot et qu'ils ne sont pas forcément experts Autopackage. alors peut-être si vraiment ça devient d'usage courant, oui, ça deviendra aussi évident que fournir des copies d'écran, mais d'ici là demander à chaque petit projet d'être un early adopter ?
est-ce à eux de résoudre ce problème d'oeuf et de la poule, d'atteindre une masse critique, alors que c'est le problème d'autres personnes ? il va falloir faire plus que leur dire "Autopackage cai bien", par exemple leur faire un beau paquet autopackage de référence bien propre de leur projet pour leur économiser 90 % du boulot de compréhension - de formation ! - à Autopackage.
(on va passer sous silence qu'il y a déjà 3 ou 4 systèmes équivallents à Autopackage et qu'en fait tu auras aussi les gens sous Mac à gérer, les gens sous PC mais avec un système 64 bits, les gens sous ARM pour les pda...)
retour à la case départ ?
[^] # Re: Une solution ... AUTOPACKAGE
Posté par Raphaël SurcouF (site web personnel) . Évalué à 5.
Comme si, sous Windows, c'était vraiment plus simple d'installer un logiciel qui a déjà été empaquetté par un tiers, que ce soit l'auteur lui-même ou quelqu'un d'autre...
Sous Windows aussi, il faut d'abord compiler le logiciel puis en faire un exécutable et ce sont pas les méthodes qui manquent, pas plus que dans le monde du logiciel libre : il existe même des solutions libres pour ce faire !
En outre, les « .exe » ne sont même pas le format « standard », s'il y en a, de Microsoft pour distribuer des logiciels car ils préfèrent utiliser des « .msi ». L'apparente simplicité de Windows cache un réel bourbier.
[^] # Re: Une solution ... AUTOPACKAGE
Posté par PLuG . Évalué à 1.
mais pas mal de soft exigent que l'utilisateur puisse ecrire dans "program files". De plus les soft ne peuvent pas vérifier de dépendances et viennent donc avec leur copie de librairie installée dans son coin a lui. Résultat, impossible de garantir que la faille de sécu liée a la librairie zip.dll est bien corrigée vu qu'on en a plusieur versions sur le système installées de partout.
On est loin, très loin de ce que réalisent les packageurs sous linux.
Autre point de vue, il est bien plus simple de creer des installeurs pour un seul OS (windows) que pour tous les OS linux. Ce serai bien que les packages marchent sur tous les OS linux, mais pourquoi pas sur les BSD aussi et les MAC OS X ? Il n'y a pas un OS linux, mais il y a autant d'OS que de distributions basées sur le kernel linux. Pensez-vous que les logiciels d'aujourd'hui s'installent sur les windows NT4 ou 98 ? ben non, ça ne marche plus, a cause des dépendances ...
# Trop d'imprecision tue la reflexion
Posté par GnunuX (site web personnel) . Évalué à -9.
Tu as mal compris.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par Volnai . Évalué à 2.
[...]cf. wikipedia à propos du Linux Standard Base)[...]
Tu as mal compris.
http://en.wikipedia.org/wiki/Linux_Standard_Base
For example, the LSB specifies that software packages should be delivered in Red Hat's RPM format, which was invented much later than Debian's deb package format
Je ne sais pas si wikipedia a tort, ou si on est deux à ne pas comprendre l'anglais, mais moi je trouve qu'il à bien compris ce qu'il a lu.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par GnunuX (site web personnel) . Évalué à 1.
Il existait d'autre packages avant et même encore aujourdhui.
Donc non, il (et tu) as mal compris.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par zerbro . Évalué à 3.
Einstein disait "tout est relatif"...
[^] # Re: Trop d'imprecision tue la reflexion
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Trop d'imprecision tue la reflexion
Posté par GCN (site web personnel) . Évalué à 6.
[1] - http://www.archlinux.org/pacman/
[^] # Re: Trop d'imprecision tue la reflexion
Posté par andeus . Évalué à 2.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par Yth (Mastodon) . Évalué à 1.
Archlinux est parti de la slack ça a dû rester.
Les cas où c'est vraiment utile d'avoir juste un bout d'un logiciel sont tout de même très rares, surtout si on considère que le système est là pour permettre le développement d'applis, et la compilation de logiciels. Ce qui est généralement un bon choix pour faire une distrib qui ne soit pas hyper-ciblée.
Bref à mon avis ce débat tient du troll, des goûs et des couleurs, il y a des plus et des moins de chaque côté, le système tout découpé n'étant pas optimal non plus : plus de boulot côté maintenance, plus de paquets installés, possibilité de se faire feinter par une découpe à laquelle on n'avait pas fait gaffe...
Yth, les dépendances, c'est pour les faibles...
[^] # Re: Trop d'imprecision tue la reflexion
Posté par GCN (site web personnel) . Évalué à 4.
Philosophiquement elles sont peut-être proche, mais ArchLinux est fortement inspirée de Crux (que je ne connais pas donc je me base sur cet article Wikipedia :) [1].
Sinon concernant la "non-granularité" des paquets ArchLinux c'est clairement voulu et ça ne risque pas de changer demain. Ancien Mandrakeux j'ai trouvé ça un peu relou au début et, finalement (surtout avec les HDDs que l'on trouve de nos jours) on s'y fait et ça ne gêne pas plus que cela (du moins, moi ça ne me gêne pas du tout).
[1] - http://fr.wikipedia.org/wiki/Arch_Linux
[^] # Re: Trop d'imprecision tue la reflexion
Posté par Croconux . Évalué à 3.
Tu suppose que tous les utilisateurs touchent un peu à tout. Ca fait beaucoup de suppositions. Il me semble qu'un grand nombre d'utilisateurs ne codent pas (ou codent avec un langage de script type python/ruby/perl). Pour ces utilisateurs, avoir toutes les bibliothèques de développement n'est pas franchement utile.
Sinon un autre avantage que je vois est de limiter la bande passate utilisée pour le téléchargement de paquets. Inutile de télécharger la totale si on n'en utilise qu'une partie. Idem lors de mises à jour de sécurité. Si une faille est trouvés dans un programme inutile de re-télécharger le tout. Les paquets contenant les données étant en général très volumineux, les admins des miroirs apprécieront.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par Yth (Mastodon) . Évalué à 2.
Non, je dis qu'on considère un OS destiné à être utilisé à la fois par des touche-à-tout et des gens qui veulent juste un truc à utiliser.
C'est la masse de tout les utilisateurs du système qui est globalement touche-à-tout, pas chacun pris individuellement.
Après on peut concevoir un système Linux destiné spécifiquemlent à des gens qui n'iront pas voir, et là virer les bibliothèque de développement et pas mal de machins comme les docs, qui ne serviront pas au public visé. Mais ce n'est pas le cas de la Slack, de la Debian, de la Fedora, de la Mandriva, d'Arch Linux, etc.
Fallait juste lire la fin de mon paragraphe :
« Ce qui est généralement un bon choix pour faire une distrib qui ne soit pas hyper-ciblée. »
Pour le coup de la bande passante, je sais pas, faudrait voir si vraiment on a une réelle différence, à l'usage. Ca se verrait sûrement sur des gros morceaux, comme OOo, ou samba, ou encore java, ou LaTeX, mais ça arrive vraiment sur des systèmes avec des paquets découpés d'avoir des mises à jour de juste une partie de ces logiciels ?
De toute façon quand tu passes de KDE 3.5.3 à KDE 3.5.4, tu vas tout retélécharger...
Après s'il s'agit de corrections de failles dans ssh, apache, dnsmasq, proftpd, ce n'est pas très lourd pour le logiciel complet.
Je pense que c'est vraiment une question de goûts, et que finalement les avantages et les inconvénients se valent.
Yth.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par xsnipe . Évalué à -1.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par Yth (Mastodon) . Évalué à 1.
Apache et PHP sont deux logiciels différents, et quelle que soit la distrib ils sont empaquetés séparéments.
Comme Zope et Python.
La question ici c'était d'avoir des paquets mysql-server, mysql-devel, mysql-lib, etc. et si tu veux juste installer un logiciel qui utilise les lib mysql, tu installes juste mysql-lib, si tu veux développer ou compiler des trucs nécessitants mysql tu mets mysql-devel, et si tu veux faire tourner un serveur mysql tu mets mysql-server.
Ou alors tu as un paquet mysql qui regroupe tout ça et basta, au pire ton serveur mysql est installé mais pas démarré si tu as juste besoin des libs ou si tu fais du dev mysql sans avoir besoin de démarrer un serveur.
C'est pas comme si un serveur no démarré ajoutait vraiment des trous de sécurité hein ^^
Yth.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par xsnipe . Évalué à -1.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par Pascal . Évalué à 3.
Un paquet Slack n'est pas un simple tar.gz. En effet, il peut contenir des scripts d'installations (un peu comme les debian), et un petit descriptif du contenu du paquet qui s'affiche lorsque tu l'installes.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Trop d'imprecision tue la reflexion
Posté par Mark Havel . Évalué à 3.
Après, c'est clair que la distribution des paquets est parfois assez bordélique sous Linux et le plus rageant, c'est qu'il arrive parfois qu'il soit plus simple d'installer les versions Windows de ces programmes que les versions Linux. Je pense qu'il y a effectivement peut-être des progrès à faire en la matière.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par Gniarf . Évalué à 0.
pourquoi pas "orangé" ou "avec un arrière-goût de betterave" ?
[^] # Re: Trop d'imprecision tue la reflexion
Posté par Yth (Mastodon) . Évalué à 6.
Le format n'y fait rien, et tous pourraient être en .tgz, ou tar.bz2, par exemple, sans qu'il n'y ait d'ajout ou de suppression de fonctionnalité.
Yth.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par Sylvain Sauvage . Évalué à 3.
Cependant, le terme de format est polysémique. Dans la phrase précédente, ainsi que dans ta dernière phrase, il s'agit du format binaire, de la couche physique du transport des informations. Mais le format, c'est aussi toutes ces méta-informations qui traînent dans l'archive. C'est la couche logique. C'est le fait que l'archive contient telle et telle information.
Ceci fait que tu peux dire « le format n'y fait rien » et que je peux répondre « le format y fait tout » sans pour autant que l'un de nous ait tort...
[^] # Re: Trop d'imprecision tue la reflexion
Posté par Yth (Mastodon) . Évalué à 2.
Disons que la façon d'empaqueter a relativement peu d'importance, ce qui compte ce sont les informations supplémentaires embarquées dans le paquet.
Donc .tgz, .deb, .rpm, aucune importance en soi.
Yth.
[^] # Re: Trop d'imprecision tue la reflexion
Posté par imalip . Évalué à 2.
D'autant que pour la petite histoire, un .deb n'est rien d'autre que 2 .tar.gz dans une archive au format ar... :)
[^] # Re: Trop d'imprecision tue la reflexion
Posté par spotty . Évalué à 1.
Les deb datent de mars 1995
http://fr.wikipedia.org/wiki/Debian
Et redhat
En fait, la phrase le package LSB pour debian est plus ancien que le package pour RedHat, et non pas, le DEB est plus ancien que le RPM
Juste pour être clair
# Mon avis à moi...
Posté par Teotihuacan . Évalué à 7.
Au sujet d'un système de paquet unique : je trouve que c'est une très bonne idée (notemment pour avoir des GUI plus poussées car il y aurait plus de contributions).
Cependant, je vois difficilement comment un paquet pourrait être compatible entre deux distrib. Un programme utilise des librairies, et toutes les distrib n'ont pas les mêmes. (version, etc...)
Il y aurait bien la solution des "paquets sources". Qui se compile en fonction des libs qui sont installées. Mais perso, je refuse d'uiliser une distrib 100% source (style Gentoo). Je ne dis pas que c'est pas bien, je dis que ce n'est pas pour moi.
Dans ce cas quid d'un système hybrid ? :
- Les paquets de la distrib sont binaires
- Les paquets sur les sites offiiels sont source. (ils se compile + installe les paquets binaire manquant dans la distrib)
Problème (mais pas le seul): c'est beaucoup de boulot de changer un système de paquet. Sachant que de toute façon les paquets devront être fait séparément pour chaque distrib. Surtout que des distrib il y en a beaucoup.
Mais sinon, je trouve l'idée intéressante ça m'aurait tenté de participer à un projet dans ce style.
Pour les fichier caché, où veux-tu les mettre ?
Par contre je suis d'accord qu'il faut limiter le nombre de répertoires. C'est un peu le cas avec les appli KDE et Gnome.
Voilà.
[^] # Re: Mon avis à moi...
Posté par Gael Tessier . Évalué à 4.
Pour les fichier caché, où veux-tu les mettre ?
Par contre je suis d'accord qu'il faut limiter le nombre de répertoires. C'est un peu le cas avec les appli KDE et Gnome.
Moi, ils ne me dérangent pas mais dans les applications qui ne les filtrent pas, je peux comprendre que ça pose problème. Les fichiers de configuration pourraient alors être tous regroupés dans un unique dossier ".etc" dans le dossier personnel, où chaque application créerait les fichiers et dossiers de son choix.
Pour ce qui est de KDE ou Gnome, le problème est plus embêtant je trouve. Il ne devrait pas y avoir de dossier comme "Desktop", "Téléchargements", "Musiques" ou "Vidéos" créés à la racine du dossier personnel. Ca pollue le dossier home inutilement si l'utilisateur ne se sert pas de ces dossiers.
--
http://www.tessier-net.org
[^] # Re: Mon avis à moi...
Posté par Marc Poiroud (site web personnel) . Évalué à 2.
KDE par défaut ne créé que le Desktop qui est utilisé pour les icônes sur ton bureau.
A ma connaissance seule Mandriva créé les répertoires "polluant" ...
[^] # Re: Mon avis à moi...
Posté par Raphaël G. (site web personnel) . Évalué à 2.
En effet, ça donne un style par défaut de classement de fichiers !
De plus sous kde ça permet d'avoir un lien direct vers ces divers répertoire dans le sélecteur d'ouverture/sauvegarde de fichier.
Donc vous ça ne vous plaît pas, mais je trouve au contraire que c'est une bonne idée et ça permet a l'utilisateur de base d'éviter le syndrome tout dans le /home !
Soit dis en passant, ou peux toujours s'en passer si on veux ;)
[^] # Re: Mon avis à moi...
Posté par modr123 . Évalué à 3.
[^] # Re: Mon avis à moi...
Posté par Teotihuacan . Évalué à 2.
Ah ? Et pourquoi ça ?
D'ailleurs je ne vois pas pourquoi le dossier Desktop dans ~ est gênant... perso, je préfère que le bureau soit accessible comme ça, en ouvrant un dossier dans mon répertoire perso.
D'ailleurs, je trouve que sur Windows c'est bizarre la gestion des répertoire spéciaux. Tout en haut de l'arborescence, il y a le bureau. Qui est aussi accessible dans c:/..../bureau. Je conçois que ce ne soit pas c: le haut de l'arborescence, mais perso, j'aurais mis le poste de travail.
Tout ça aussi pour dire que je ne vois pas le lien avec Windows.
[^] # Re: Mon avis à moi...
Posté par modr123 . Évalué à -1.
ce genre de repertoire est d'abord apparu sous windows dans le dossier mes documents et pour ne pas depayser les windowsiens on a fait de même
[^] # Re: Mon avis à moi...
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Mon avis à moi...
Posté par modr123 . Évalué à -2.
je maintien l'apparititonde ce genre de choses a été faites pour pas depayser les windowsiens Ok ?
[^] # Re: Mon avis à moi...
Posté par Thomas Douillard . Évalué à 1.
[^] # Re: Mon avis à moi...
Posté par modr123 . Évalué à -3.
demontres moi que j'ai tord
a) je n'utilise pas ce genre de dossier et ils me sont inutiles
b)ils sont venues pour ne pas depayser les utilisateurs de windows
[^] # Re: Mon avis à moi...
Posté par Thomas Douillard . Évalué à 1.
Et qui avancent des trucs, et répondent à la contradiction en réavancant le même truc, c'est vachement constructif.
Cela dit je suis un peu dans le même esprit que toi, j'irai pas aller fouiller les mailing lists kde, gnome, freedesktop ou les distribs rien que pour un troll idiot.
Dans un cas comme dans l'autre, perso je maintiens que ce n'est pas forcément une mauvaise chose, et tu ne pourras pas me convaincre du contraire (c'est une façon de mettre fin à la discussion).
[^] # Re: Mon avis à moi...
Posté par modr123 . Évalué à -5.
au fait sous windows déja je n'aimais pas
[^] # Re: Mon avis à moi...
Posté par Teotihuacan . Évalué à 4.
_ Est-ce que ça vient vraiment de Windows le fait de mettre des dossiers "Documents", "Desktop", etc... ? Je ne sais pas moi... Windows XP n'est pas le seul environnement qui existe et il n'a pas toujours existé... (ou alors ça vient de Windows ME, j'en sais rien et globalement je m'en fiche)
_ Toutes les distribs créent-elles toutes ces répertoires là ? (perso, je ne sais pas, ça fait tellement de temps que je n'ai pas eu une config par défaut...)
_ Pas la peine de crier pour deux répertoires.... tu les supprimes et 2 secondes plus tard t'en entends plus parler (et si tu gardes ton ~ même après les upgrade et sur les autre distribs, je ne vois pas pourquoi tu aurais à faire plus d'une fois...)
_ Pour le dossier "Desktop", c'est pas pareil que sur Windows (cf: mon argumentation au dessus)... et maintenant, c'est quand même mieux qu'il y a 5 ans : KDE et Gnome utilisent le même dossier pour le bureau et les éléments créé sur l'un sont utilisable sur l'autre.
_ Ce ne sont QUE des répertoires... et même si c'est inspiré de Windows, c'est pas la peine d'en faire tout un flan... c'est pas le méga hold up, c'est pas la fin du monde libre (libérons le monde libre !!!!)... les distribs ont osé violer le brevet sur les répertoires créés dans le répertoire de l'utilisateur ?
_ Il ne faut pas se leurrer, il y a plein de paradigmes qui se retrouve sur les différents environnements (libres ou pas)... on essaie parfois d'innover, mais certains concept sont (pour l'instant du moins) acquis... surtout le fait de mettre les musique dans un répertoire "musique", et tant qu'à faire, faut que ce soit dans le répertoire de l'utilisateur... OK, je sais, tu l'as dit, TU ne le fais pas, mais tu ne va pas me faire croire que tu ne classe rien... tu as bien une arborescence perso...
Bref, faut pas pousser tout de même...
[^] # Re: Mon avis à moi...
Posté par Gael Tessier . Évalué à 3.
Ce serait trop beau si c'était le cas. Malheureusement, ils sont souvent recréés automatiquement (par KDE, Gnome, Mandriva ou autre, je n'en sais rien...) et c'est dommage. Je n'utilise KDE que lorsque je n'ai pas le choix sur certaines machines au boulot, et certains amis ont été confrontés à ces répertoires qu'ils n'utilisent pas non plus et ne peuvent pas toujours supprimer.
Toutefois, ça ne sert à rien de crier il est vrai, et on peut toujours mettre un "rm -rf" dans son .bash_profile par exemple.
--
http://www.tessier-net.org
[^] # Re: Mon avis à moi...
Posté par Tonton Benoit . Évalué à 2.
Perso ça me gênerait de les avoirs, j'ai déjà un /mnt/musics un /mnt/pictures et /mnt/videos car ils sont sur des partitions séparées sur un autre disque-dur mon /home est réservé au travail !
[^] # Re: Mon avis à moi...
Posté par Ph Husson (site web personnel) . Évalué à 1.
Nan parce que bon le but est le même, même si c'est des emplacements différents
[^] # Re: Mon avis à moi...
Posté par Teotihuacan . Évalué à 2.
Ah ??? J'utilise KDE et une distrib grand public... et à part le Desktop qui doit être dans le ~, je n'ai pas pas répertoire parasites.
Tu as quels répertoires ? sur quelle distrib ? et quel version de KDE (quoique je n'ai jamais eu le pb) ?
[^] # Re: Mon avis à moi...
Posté par Raphaël G. (site web personnel) . Évalué à 6.
Et les admins pas en carton auront vite fait de trouver comment ces répertoires se créent magiquement :
Le script (un grep c rapide quand même) :
/etc/X11/xinit.d/desktop-directories
Le paquet :
$ rpm -qf /etc/X11/xinit.d/desktop-directories
desktop-common-data-2007-17mdv2007.0
Bon simpliste on met ce packet dans la liste a éviter dans :
/etc/urpmi/skip.list
Et on delete ce fichier et on vire les reps dans les répertoires des utilisateurs qui en veulent pas...
Bref, l'autre couillon qui m'a moinsser plus haut et qui pleure pour ces "windowseries" alors que c'est une belle amélioration, il a qu'a pas utiliser une distribution user friendly qui lui simplifie la vie, pour avoir des concepts immuable qui date de 25ans y a d*/s*/cequevousvoullezapartmandriva qui fait ça très bien...
(je lui conseille même un kernel linux 1.0preprepre0.0001 histoire de pas avoir un truc qui marche tout de suite sans lui poser de questions...)
</fin du mode coup de gueule anti-intégristes stupides...>
[^] # Re: Mon avis à moi...
Posté par Christophe Merlet (site web personnel) . Évalué à 7.
Ya des distribs qui ont la facheuse manie de foutre un fichier gigantesque dans /proc qui prends beaucoup de place pour rien. /proc/kcore
J'ai des machines sur lequel il monte jusqu'a 4 Go !!
[^] # Re: Mon avis à moi...
Posté par Teotihuacan . Évalué à 1.
Mais ce qui est dans /proc est virtuel, non ?
[^] # Re: Mon avis à moi...
Posté par Teotihuacan . Évalué à 1.
[^] # Re: Mon avis à moi...
Posté par GCN (site web personnel) . Évalué à 2.
Voilà, tu peux maintenant te dire qu'effectivement, c'était du second degré !
[^] # Re: Mon avis à moi...
Posté par Christophe Merlet (site web personnel) . Évalué à 10.
[^] # Re: Mon avis à moi...
Posté par Toufou (site web personnel) . Évalué à 1.
Beh dans mon boulot, tout le monde l'a mais personne ne s'en sert : autant le virer.
[^] # Re: Mon avis à moi...
Posté par Teotihuacan . Évalué à 2.
Je ne sais même pas si c'est possible de lui dire de le mettre ailleurs. (d'ailleurs, est-ce que c'est toujours dans le ~ par défaut ? Je ne sais pas, c'est pas le truc que je change tout les jours...)
Mais en fait, c'est clair que c'est pratique pour une chose : la sauvegarde des mail. Mais il ne faudrait pas que chaque appli fasse ça...
En parlant de sauvegarde, je trouve qu'un point qui devrait être étudier au niveau des environnements : comment sauvegarder, et surtout comment transférer des données perso d'un poste à l'autre...
Exemple : je suis 50% du temps sur mon ordi perso, 40% sur mon ordi au bureau, sinon, je surfe aussi sur mon téléphone ou sur mon autre ordi. Et à chaque fois, j'ai un profil différents. Mail différents, bookmark différents, agenda différents, etc...
Et fait, je pense qu'il faut que mon profil devienne mobile. C'est un peut ce que propose Google avec la page perso et le compte Google, mais je trouve ça dommage que ce ne soit pas bien pensé au niveau des environnements de bureau. Je pense que c'est un peu ce que KDE essaie de faire avec le projet aKonadi.
Mais bon, je m'éloigne...
[^] # Re: Mon avis à moi...
Posté par Ph Husson (site web personnel) . Évalué à 1.
[^] # Re: Mon avis à moi...
Posté par Mildred (site web personnel) . Évalué à 2.
Et même que sije lance evolution, il utilise le même dossier ~/Mail et je peux retrouver mes e-mails de sylpheed
Sauf qu'il reste Thunderbird qui stocke les -emails dans un dossier bien compliqué ... et sans possibilité de facilement synchroniser avec les autres lecteurs e-mail. C'est pour ça que je lui ai dit adieu (avec l'occupation mémoire)
[^] # Re: Mon avis à moi...
Posté par B16F4RV4RD1N . Évalué à 4.
à propos de :
effectivement, bien vu, je n'avais pas pensé à cela. Cela est vraiment un facteur très limitant :(
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Mon avis à moi...
Posté par Gael Tessier . Évalué à 3.
--
http://www.tessier-net.org
[^] # Re: Mon avis à moi...
Posté par gaston . Évalué à 4.
Voir ici pour plus d'infos : http://www.foo-projects.org/~benny/xfce/file-locations.html
[^] # Re: Mon avis à moi...
Posté par Yth (Mastodon) . Évalué à 2.
Et probablement d'autres aussi.
Ca ne fait pas beaucoup je pense, mais c'est assez récent, et le nombre augmente petit à petit.
De mon point de vue c'est une super bonne idée :)
Et vivement qu'ils fassent tous ça...
Yth.
[^] # Re: Mon avis à moi...
Posté par Florent Bayle (site web personnel) . Évalué à 3.
[^] # Re: Mon avis à moi...
Posté par andeus . Évalué à 3.
Il y a smart, qui je crois gère entre autre les rpm et deb. Donc même si les paquets sont différents ça permet de faire une GUI unique :)
[^] # Re: Mon avis à moi...
Posté par Teotihuacan . Évalué à 2.
Typiquement, je trouve que Synaptic et Rpmdrake (je ne sais pas comment ça s'appelle maintenant) sont de très bonnes interfaces de gestion des paquets. Je ne parle pas des outils en ligne de commande car ils sont très bon, mais ça ne m'intéresse pas ici.
Depuis quelque temps déjà, j'utilise Adept, tout ça parce que c'est ce qui est installé par défaut avec KUbuntu, mais ça ne vaut vraiment pas Synaptic.
Smart, ça vaut quoi par rapport à Adept et Synaptic ?
Si la gestion des paquets était unifiée, on aurait une interface de gestion des paquets dans KDE, une dans Gnome... et tout ça un peu mieux intégré. De plus il n'y a pas dans toutes les distribs une bonne interface pour les paquets.
Je sais, je reste focalisé sur l'interface, mais je pense que c'est un point important pour l'utilisateur.
[^] # Re: Mon avis à moi...
Posté par andeus . Évalué à 2.
Mais j'ai mis à jour une mandriva2006 en 2007 dernièrement et je l'ai fait avec smart, après des problèmes avec urpmi (problèmes de dépendances ingérables, etc..). Avec smart c'est passé beaucoup mieux, je l'ai utilisé deux trois fois après ça, et je l'apprécie beaucoup mieux que urpmi. Je crois qu'il vient aussi avec une GUI, mais j'ai pas testé.
[^] # Re: Mon avis à moi...
Posté par cremoa cremoa . Évalué à 1.
[^] # Re: Mon avis à moi...
Posté par Zakath (site web personnel) . Évalué à 9.
/usr/dtc, clairement.
# Normal
Posté par Bapt (site web personnel) . Évalué à 10.
C'est pour cela qu'il y a plein de système de package. Toi veux un .deb pour tout le monde (sache qu'il n'est pas le premier format de paquet) mais ça apporte une forte contrainte : le .deb à un certain nombre de fonctionnalité et surtout certaines méthodes pour gérer les dépendances, les preinstall, postinstall, or personne n'est d'accord pour affirmer qu'il y a une et une seule manière de gérer ces fonctionnalités, et certains trouvent même que c'est trop restrictif que de devoir les gérer par les paquets. Comme nous sommes dans du logiciel libre, si moi je ne suis pas d'accord avec les gens qui utilisent le .deb, alors je fait mon format qui va proposer les même choses, mais va le faire de manière différente tout en étant persuadé que c'est la meilleur manière de faire, d'autre vont tout simplement supprimer la plupart des contraintes et faire un gros pack plein de fichier dont 1 qui exécute des chose après l'installation : .tgz.
Tu auras beau faire tous les efforts de la terre pour uniformisé tout ça, ce ne sera jamais le cas car il y aura toujours une personne qui vera les choses autrement.
Si Windows ou MacOSX étaient libres, il y aurait aussi plein de distribution qui apparaitrait avec des formats de paquets différents, avec des architectures (emplacement des dossiers et de leur contenu différents). regarde sous Mac : les finks, portage et autres ont leurs propres formats qui ne sont pas des dmg.
Ca peut paraitre triste, mais c'est ça aussi la liberté.
Dans un autre domaine, pourquoi il n'y a pas 1 seul éditeur texte avec l'ensemble des fonctionnalités de tout le monde ? pourquoi il n'y a pas un seul et unique bureau/desktop manager/window manager ? parce que je ne veux pas de gnome ni de kde, que d'autres ne veulent que du gnome, et que d'autres encore ne jurent que par kde.
[^] # Re: Normal
Posté par arapaho . Évalué à 3.
C'est déjà le cas ! emacs et ion [ça sert à quoi déjà le desktop manager ?].
[^] # Re: Normal
Posté par Thomas Douillard . Évalué à 5.
[^] # Re: Normal
Posté par B16F4RV4RD1N . Évalué à 2.
Je n'évoquais pas que les paquets, mais également la hiérarchie. Même si on ne peut plaire à tout le monde, faire des consensus c'est dire "j'accepte cela, mais en échange je fais valider ceci" etc, quitte a également faire une surcouche pour faciliter la transition.
Tu évoquais macosx, justement la multiplicité des efforts et la non centralisation par apple fait que l'on a :
- des systèmes plutôt mal garnis (chacun à un peu de tout, et parfois cela entre en conflit)
- des binaires parfois très obsolètes
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Normal
Posté par Gniarf . Évalué à 6.
non, ça s'appelle du design by committee et ça a toujours donné de la merde dans l'histoire de l'informatique, que ça soit CORBA, les versions évoluées de SQL... hyper-complexe et imbitable, on essaye de faire une girafe et on finit avec un ornithorynque bicéphale.
les seuls cas où ça n'a pas donné des bouses incroyablement complexes, ça a été quand dès le départ on s'est attaché une main dans le dos et en refusant tout gadget, toute déviance par rapport à un dénominateur commun forcément squelettique. résultat au final on ne faisait pas grand chose, mais ça restait simple. les premières incarnations de Java furent ainsi : pas de gestion du bouton droit puisque les Mac n'en ont pas, etc etc...
ah, et quand tu parles de consensus et de compromis à atteindre entre acteurs des distributions, euh non merci, je n'ai pas la moindre envie de devoir subir les contraintes de distributions que je n'utilise pas, ou pire celles d'architectures dont je n'ai rien à secouer.
[^] # Re: Normal
Posté par Mildred (site web personnel) . Évalué à 2.
Mais c'est vrai que pour avoir essayé ubuntu sur une machine apple, et sans bouton droit à la souris, pas facile de l'utiliser (le ctrl-clic ne marche évidament pas et la souris bluetooth n'est pas reconnue)
[^] # Re: Normal
Posté par guitouu . Évalué à 0.
Je trouve que c'est vraiment très négatif comme vision.
> Certains problèmes ont plusieurs solutions
Ca c'est certain.
Mais c'est pas pour autant que tu ne trouveras pas une majorité de personnes pour se mettre d'accord et definir une norme.
Je ne dis pas que la norme sera parfaite pour tout le monde. C'est la qu'il faut savoir faire des compromis et des concessions !!!
Et une fois que la norme existe, les gens la suive petit à petit pour ne pas etre exclu du systeme. Car la norme a pour but de rassembler et de simplifier l'utilisation au quotidien ...
Bref, une fois que c'est fait, les 3 ploucs qui continuent à faire leur cuisine autour de leur totem en chantant des musiques payardes se retrouvent vite sans soutient et ne dérangent personne.
cf opendocument par exemple...
[^] # Re: Normal
Posté par Toufou (site web personnel) . Évalué à 3.
Pour définir une norme par type de solution désirée plutot : combien de normes existe-t-il pour gérer des documents ? Ou pour faire du chat ?
Une norme ne résoud rien, elle ne fait que définir et spécifier une manière de faire parmis d'autres.
C'est la qu'il faut savoir faire des compromis et des concessions !!!
Il y a des concessions que tu ne peux pas faire car certaines conditions sont innacceptables. Par exemple, si tu veux faire une distro basée sur une init BSD, tu ne peux pas facilement accepter la LSB qui t'impose presque un init systeme V car c'est à l'encontre de la philosophie de ta distro.
Car la norme a pour but de rassembler et de simplifier l'utilisation au quotidien ...
J'espère qu'aucune norme n'a pour but de rassembler sinon elle devient guidée par des choix marketting (satisfaire le plus grand nombre) plutot que par des choix techniques et là, on obtient sur un yahourt infernal.
Bref, je ne vois pas ce qu'il y a de négatif dans ce qu'il dit. Je trouve nettement plus négatif le fait de dénigrer ceux qui ne suivent pas la norme qui te plait et de proposer qu'on les ignore uniquement parce tu ne vois pas l'intéret de leur démarche.
[^] # Re: Normal
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
C'est d'ailleurs pour ce type d'activité que j'ai imaginé les RMLL fin 1999.
Pour mémoire, les RMLL 2007 auront lieu à Amiens.
# Les limites du système de packaging actuel
Posté par Bruno Coudoin (site web personnel) . Évalué à 10.
En partant du principe qu'un utilisateur n'a pas à compiler un logiciel, voici un exemple de chose qu'on ne sait pas faire :
- Installer un logiciel sur un système en tant qu'utilisateur normal. Le système urpmi/apt-get ne le permettent pas, ou les logiciels packagés ne le supportent pas (non relogeable).
- Installer la version N-1, N+1 d'un logiciel. Non monsieur, vous devez utiliser celui qui est livré avec votre distribution.
- Installer la version N et N+1 d'un logiciel. Utile pour tester avant une migration, ou utiliser / tester de nouvelles fonctionnalités en gardant l'ancienne version.
- Installer un logiciel qui n'a pas été packagé dans sa distro. (Mauvaise distro n'est pas une réponse).
Ça parait absurde mais windows permet tout cela.
Un autre exemple concret, les distro ne packagent pas les versions BETA de GCompris et c'est une bonne chose. Mais comment faire pour que les utilisateurs finaux (parents, professeurs) puis tester. Il ne savent pas compiler donc ne testent pas le logiciel. On pert l'intérêt du logiciel libre car on se retrouve coupé de la base des gens qui voudraient vous aider.
Je distribue maintenant GCompris au format autopackage. Je n'ai pas beaucoup de retour, mais ça à l'air de fonctionner. Il est temps d'aprés moi que l'on prenne ce problème sérieusement.
Il n'est pas non plus question de dire qu'autopackage remplace quoi que ce soit, c'est juste un outil suplèmentaire pour aider nos utilisateurs.
[^] # Re: Les limites du système de packaging actuel
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
- C'est parfois possible, mais uniquement en jouant sur le nom du paquet (apache, apache-2.0, linux-2.6, linux-2.4) mais c'est vrai qu'une vrai gestion des versions serait pratique
- Sous windows, c'est possible mais cela peut vite tourner à la catastrophe. C'est le même genre de fonctionnalité que le 2ième point.
Il me semble que KDE a sorti un truc pour ça : Klic (?)
- Donc tu va cherché quoi ? Les sources ? Un "paquage binaire universel" ? (cela rejoind mon idée de paquage light de soft plus bas)
"La première sécurité est la liberté"
[^] # Re: Les limites du système de packaging actuel
Posté par Seazor . Évalué à 1.
-pas besoin de root
-un fichier à dl pour tout le programme
Site officiel de klik
http://klik.atekon.de/
[^] # Re: Les limites du système de packaging actuel
Posté par Bruno Coudoin (site web personnel) . Évalué à 1.
Il existe plusieurs solutions qui proposent des packets binaires :
- autopackage http://autopackage.org/
- 0install http://zero-install.sourceforge.net/
- klik http://klik.atekon.de/
A terme, pour qu'une solution pérène puisse voir le jour, il faut avoir dans les distros une base commune. Cette base est en cours de définition au niveau du LSB http://www.freestandards.org/en/LSB . Ainsi, on pourrait imaginer qu'un packet binaire puisse être garantit LSB X.Y.
L'utilisateur devrait juste savoir quelle version de LSB est sur sa distro. Si nécessaire, les développeurs peuvent faire l'effort de maintenir leur logiciel sur une version antérieur du LSB pour ne pas forcer les utilisateurs installer une distribution récente.
D'ailleurs, le LSB prend ce problème en considération http://www.freestandards.org/en/DesktopWG :
Next steps (Etapes suivante)
* Packaging and installation requirements for applications
[^] # Re: Les limites du système de packaging actuel
Posté par B16F4RV4RD1N . Évalué à 1.
http://klik.atekon.de/
là où cela me dérange un peu (et pourtant j'adore kde), c'est que c'est trop lié à kde
Je préfère autopackage en ce cas. Il existe également zero-install : http://zero-install.sourceforge.net/ (jamais testé)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Les limites du système de packaging actuel
Posté par patrick_g (site web personnel) . Évalué à 3.
Je suis donc allé sur le site Abiword et j'ai vu qu'il y avait une version 2.4.5 au format Autopackage. Je me suis dit "pourquoi pas ? Je vais tester"
3 clics plus tard j'avais Abiword 2.4.5 installé sur mon ordi ! Trop facile !
Le seul (minuscule) problème c'est que dans le menu Applications de ma Dapper je n'avais que l'intitulé "Traitement de texte Abiword" pour lancer mais je n'avais pas la jolie icône.
En résumé je privilégie toujours les dépots officiels Ubuntu mais pour des besoins très ponctuels je trouve qu'Autopackage est bien foutu.
[^] # Re: Les limites du système de packaging actuel
Posté par B16F4RV4RD1N . Évalué à 2.
D'ailleurs en ce moment je n'ai pas internet chez moi, je voulais installer audacity, j'ai récupéré le rpm pour ma distribution, et il manquait trop de dépendance. J'aurais bien aimé un autopackage dans ce genre de cas.
Je pensais essayer de le recompiler depuis les sources, mais quand on lit ce genre de chose :
"La bibliothèque wxWidgets est indispensable. Audacity 1.2 nécessite wxGTK 2.4 compilé sans les options gtk2 et unicode. (Les versions futures de Audacity supporteront les versions plus récentes des bibliothèques GTK et wxWidget.)" cela ne donne pas trop envie (de toute façon je n'ai pas les paquets de dev de wxwidgets d'installé)
http://audacity.sourceforge.net/download/source
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Les limites du système de packaging actuel
Posté par Marc Poiroud (site web personnel) . Évalué à -3.
Pour des raisons évidentes de sécurité et stabilité, heureusement que c'est impossible !
Pour les autres points >> Slackware et /opt sont les réponses.
Tu peux installer les versions de ton choix et installer un paquetage .rpm et .deb
Pour les BETA, faut aussi voir que beaucoup d'utilisateurs BETA signifie "Fait planter la machine" donc c'est plus psychologique que technique.
J'ai compilé Gcompris sous Slack pendant un moment, mais j'ai abandonner à cause des dépendances qui augmente plus vite que la compilation ... et aussi que je suis passer sous Archlinux :D
http://poiroud.free.fr/linux/slackbuild/gcompris/
[^] # Re: Les limites du système de packaging actuel
Posté par Bruno Coudoin (site web personnel) . Évalué à 3.
A bon, alors pourquoi un utilisateur peut recompiler et utiliser un logiciel en l'installant dans son home ? Pourquoi on permet au gens qui savent compiler plus de chose qu'aux autres. GNU/Linux doit-il rester un système réservé à une élite ?
En quoi est-ce dangeureux de permettre au gens d'installer les logiciels dont ils ont besoins.
Au passage, merci pour les packets slackware de GCompris ;)
[^] # Re: Les limites du système de packaging actuel
Posté par Marc Poiroud (site web personnel) . Évalué à 1.
Un logiciel dans le home ne risque pas de compromettre le système si l'installation part en sucette.
Mais je peux aussi te répondre pour le cas GCompris.
Qu'es ce qui t'empêche TOI de proposer une archive binaire à décompresser dans le /home ou encore dans /opt.
Moi aussi parfois j'aimerais pouvoir tester facilement un soft ... comme Firefox 3.0 Minefield, où j'ai récupérer le tar.gz sur les serveurs de la MoFo, je l'ai décompressé, fait une copie de mon .mozilla et lancé ./firefox et pouf ça marche ;)
Donc parfois, il faut simplement utiliser ce que l'on a, et une archive binaire sur laquelle l'utilisateur fait "Clic droit » Extraire ..."
C'est une idée, je dit pas que c'est la solution magique mais peu être une piste à réfléchir, surtout que Gcompris fait parti de la machine de mes gosses depuis la 6~ et j'ai fait quelques retour sur la ML francophone quand je le compilais pour la Slack car je trouve GCompris vraiment très bien ;)
[^] # Re: Les limites du système de packaging actuel
Posté par z a . Évalué à 1.
[^] # Re: Les limites du système de packaging actuel
Posté par Yth (Mastodon) . Évalué à 2.
installpkg -root $HOME/usr nom_du_paquet.tgz
Ca marche.
Je pense que c'est aussi possible avec les autres, c'est le bon plan pour installer un système paquet par paquet : créer la partition, la formater, la monter dans /base/ (par exemple), et installer les paquets avec /base/ comme racine. Lancer ldconfig avec chroot dans /base/ (chroot /base /sbin/ldconfig) et voilà :)
Yth.
[^] # Re: Les limites du système de packaging actuel
Posté par Emmanuel C . Évalué à 0.
Au pire, tu ne pert que ton home, et pas le système complet. Cela était parfaitement cohérent à une époque, mais il est vrai que maintenant, on tient plus à ses données qu'à son systeme (que l'on peut réinstaller en trois cliques) et peut-être qu'il serait sage d'engager une reflexion sur ce point d'ailleurs. Cela dit, dans les faits, cela évite de faire pas mal de bétise quand même...
Evidemment, quand on parle d'administrateur et d'utilisateur, on parle de rôle : sur un pc personnel, il serait absurde qu'un utilisateur ne soit pas administrateur de la machine. C'est d'ailleurs ce que fait Ubuntu : pas de root en tant que tel, mais pour faire des choses potentiellement sensibles sur la machine, il faut montrer patte blanche, et valider que l'on fait une opération importante pour le système. Il n'y a donc pas d'opérations réservées à une élite, mais simplement des opérations protégées.
[^] # Re: Les limites du système de packaging actuel
Posté par lolop (site web personnel) . Évalué à 2.
Malheureusement ça ne l'est pas (la pluspart du temps) en utilisant les outils de gestion des packages.
Pourtant, un ./configure avec l'option qui va bien permet d'installer tout plein d'applications là où on le veut (j'ai souvent un altroot dans mon ~/ afin d'y retrouver les bin usr etc... pour les softs recompilés dans mon compte).
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Les limites du système de packaging actuel
Posté par alice . Évalué à 2.
Les installateurs de type Adept ou Synaptic demandent juste un mot de passe, ça n'est pas très compliqué.
Je faisais tout ça quand j'étais sous windows, résultat le système se pourrissait petit à petit et il fallait réinstaller tous les 3 mois. Depuis j'ai gardé mes distributions linux durent 1 an ou 2 an et ce n'est pas la stabilité qui me fait changer, mais l'envie de voir autre chose. Mes parents ont une knoppix depuis 3 ans qui tourne toujours aussi bien qu'au début.
Pour ceux qui toujours les dernières versions il y a Gentoo...
[^] # Re: Les limites du système de packaging actuel
Posté par Bruno Coudoin (site web personnel) . Évalué à 0.
C'est parce que certains logiciels écrasent des librairies systèmes ce qui n'est pas acceptable. Remarque que ce n'est pas indispensdable. Je fournis un installeur GCompris pour windows qui n'écrase rien.
[^] # Re: Les limites du système de packaging actuel
Posté par symoon . Évalué à 2.
Faux en ce qui concerne Debian.
La possibilité n'est pas intégrée à une distribution "par défaut" pour des problèmes de place sur les miroirs. En revanche, il suffit d'utiliser snapshot.debian.net pour pouvoir installer n'importe quelle version antérieure d'un logiciel précis.
Exemple :
http://snapshot.debian.net/package/firefox
[^] # Re: Les limites du système de packaging actuel
Posté par Bruno Coudoin (site web personnel) . Évalué à 1.
[^] # Re: Les limites du système de packaging actuel
Posté par Raphaël SurcouF (site web personnel) . Évalué à 6.
[^] # Re: Les limites du système de packaging actuel
Posté par Croconux . Évalué à 2.
- Installer la version N et N+1 d'un logiciel. Utile pour tester avant une migration, ou utiliser / tester de nouvelles fonctionnalités en gardant l'ancienne version.
(...)
Ça parait absurde mais windows permet tout cela.
Ca dépend beaucoup du logiciel, ça. Sous Windows, la plupart des logiciels installent leurs dll à la porc en écrasant les versions précédentes. Donc même si tu peux théoriquement installer la version n+1/n-1 dans un autre répertoire, la deuxième installation risque fort d'atomiser la première. Autre avantage du système de paquets : Il est possible de revenir en arrière. Je peut installer la version n+1 et si elle ne me convient pas, je peut remettre la version n. Les fichiers de configuration sont sauvegardés et je sais que je pourrais remettre ma machine dans l'état ou elle était avant.
Un autre exemple concret, les distro ne packagent pas les versions BETA de GCompris et c'est une bonne chose. Mais comment faire pour que les utilisateurs finaux (parents, professeurs) puis tester. Il ne savent pas compiler donc ne testent pas le logiciel. On pert l'intérêt du logiciel libre car on se retrouve coupé de la base des gens qui voudraient vous aider.
Pourquoi ne pas distribuer des versions binaires liées statiquement ? Nexuiz par exemple propose des archives toutes bêtes. Il n'y a qu'a détargéziper dans un répertoire et cliquer sur le programme (pas besoin d'être root en plus).
[^] # Re: Les limites du système de packaging actuel
Posté par Bruno Coudoin (site web personnel) . Évalué à 1.
Il n'est pas possible de faire une version statique de GTK. GTK utilise des modules dynamique, par exemple pour afficher des images. Si je fais un binaire statique, les utilisateurs ne pourront pas charger les images et dans le cas de GCompris, c'est très embétant ;)
[^] # Re: Les limites du système de packaging actuel
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Les limites du système de packaging actuel
Posté par Bruno Coudoin (site web personnel) . Évalué à 1.
[^] # Re: Les limites du système de packaging actuel
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Les limites du système de packaging actuel
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
En effet, ça dépend beaucoup du logiciel.
Mais sous Windows, la plupart des logiciels tiers (c-a-d non fournis par l'éditeur du système d'exploitation) installent tous leurs fichiers dans un seul et même répertoire et éventuellement quelques clés dans la base de registre. En clair, on pourrait considérer que le répertoire « Program Files » est équivalent au répertoire « /opt » sous les systèmes Unix.
On peut donc installer des versions concurrentes d'un même logiciel (pour peu qu'elles ne dépendent guère trop du système (en général, elles sont justement compilées en statique). Et il est bien sûr possible de revenir en arrière pour peu qu'on ait conserver l'archive du précédent logiciel.
[^] # Re: Les limites du système de packaging actuel
Posté par gnujsa . Évalué à 7.
> [...]
> Ça parait absurde mais windows permet tout cela.
Ça m'est arrivé plus d'une fois de récupérer un .deb d'une version inférieur à celle fourni par apt et de l'installer à coup de dpkg. dpkg me signale que je vais rétrograder de version, mais s'exécute docilement. Hormis des éventuelles questions de dépendances, le seul problème que ça peut poser, c'est la restauration de la version N lors d'une mise à jour. Il faut donc ajuster le Pin-Priority
dans /etc/apt/preferences. Ok, c'est pas du tout user-friendly, mais transposé dans le monde windows, c'est comme si tu essayais de faire prendre en charge ton logiciel (gcompris ?) par WindowsUpdate !
> Installer la version N et N+1 d'un logiciel.
- J'ai actuellement firefox 1.5.0.7 (fourni par Debian), firefox 2 dans /usr/local (installeur MoFo) et firefox 3 alpha détargzipé dans mon home ainsi que iceweasel et swiftfox (paquet .deb).
Un même logiciel en 5 versions différentes, avec différent type d'installation: paquet deb officiel, paquet deb non-officiel (nouveau nom), installeur dans /usr/local, détargzip dans le home
- J'ai également vim-gtk, vim-gnome, vim-perl, vim-basic, vim-full, installé en parallèle. Tous ces paquets sont officielement fournis par Debian. Ils fournissent le même binaire (/usr/bin/vim). C'est possible grace au mécanisme des alternatives. Un autre mécanisme plus rustique s'appelle diversion. (altenatives à depuis été porté et intégré sur d'autres distro, RPM entre autre). Le mécanisme des alternatives est surtout intéressant en ligne de commande. En mode graphique, avec le ".desktop" qui va bien, c'est superflu.
- une recherche sur le site Debian avec comme mot clef "-ng" renvoie 36 réponses: ng pour next génération, c'est à dire pour pouvoir installer l'installer en parallèle de la version stable . une recherche sur "-beta" renvoie 9 résultats. Et il y a encore d'autre façon de nommer.
Pour une installation "rapide et sale" dans le home, il existe aussi le format shar ."shell archive".
J'ai pas l'impression que ce soit vraiment plus compliqué sous linux que sous windows, excepté le fait que sous linux, on a tendance à vouloir faire plus propre (pas installer n'importe ou, n'importe comment) et aussi que linux est beaucoup plus varié (distribution et donc dépendance, plateforme matériel) Mais sous Windows, comme sous linux, il existe plusieurs sorte d'installeur, et si tu t'en tiens aux mises à jour Windows, tu ne pourra pas installer, par exemple, IE5 + IE6 + IE7 en parallèle.
Je donne des exemples pour Debian, mais je suppose qu'il existe le même genre de mécanisme pour RPM. Pour en revenir à ton problème, pourquoi ne pas fournir, un paquet gcompris-ng ? Autopackage fonctionne plutôt bien à court terme, mais on perd la mise à jour auto via le système de paquetage, ce paquet n'est pas gérable par la même interface que les autres paquets , ...
# paquage light
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Il faudrait un truc standard qui définit des menus, des chemins relatifs, qui s'execute en droit pas root, pour éviter que le ne fasse des trucs pas beau, qui déclare le compil utiltisé et les lib dont il dépend. Mais tout cela sans script.
Cela serait bien utile pour oracle et autre qui ne supporte au final que red hat.
"La première sécurité est la liberté"
[^] # Re: paquage light
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Les logiciels propriétaires vont généralement être parqués dans « /opt » :
http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICA(...)
# La conscience libre commune l'a fait exprès
Posté par jeje99 . Évalué à 1.
C'est quand même plus facile de filer les sources pour laisser les gestionnaires de dépots réaliser les packages.
[^] # Re: La conscience libre commune l'a fait exprès
Posté par 태 (site web personnel) . Évalué à 2.
[^] # Re: La conscience libre commune l'a fait exprès
Posté par Gniarf . Évalué à 3.
[^] # Re: La conscience libre commune l'a fait exprès
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Un éditeur de logiciels propriétaires se tournera vers les acteurs/distributions dont le
« marché » leur assurera un retour sur investissement.
Ensuite vient l'assurance d'une société tierce qui puisse assurer le support du logiciel propriétaire sur ce système que l'éditeur, par définition, ne maîtrise pas.
Ce n'est donc pas pour rien qu'on trouve principalement des paquets binaires pour RedHat parfois pour SuSE et quasiment pas pour les autres distributions.
Mandriva a encore du mal à convaincre visiblement ces fameux éditeurs et la toute récente Ubuntu pourra certainement un jour tirer son épingle du jeu.
Par contre, Debian, sans le soutien d'une société commerciale, ne pourra rassurer elle-même ce genre d'acteurs. Des constructeurs comme HP ou IBM semblent vouloir cependant assurer un tel support mais on en reste encore qu'aux promesses.
Pour finir, Oracle vient tout juste d'annoncer qu'ils comptaient fournir une « distribution » de leur cru, nommée « Unbreakable Linux », mais je pense qu'il s'agit davantage des débuts d'une offre d'appliance qu'un désaveu du support de RedHat.
# Fichiers de configuration et « bases de registres »
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
Les principaux acteurs ne sont pas responsables des fichiers de configuration qui sont ainsi créés dans le dossier de l'utilisateur. Le projet Gnome (et KDE sans doute) essaie de pallier à cela avec Gconf qui est un équivalent de la base de registre mais nécessite une forte dépendance avec les bibliothèques de Gnome.
Les différentes distributions s'en accomodent tant qu'elles le peuvent.
# pas un gestionnaire de paquet identique, mais une structure peut-etre ?
Posté par mornik . Évalué à 2.
Pour moi le répertoire Desktop est une plaie. J'utilise xfce 4.2, et avoir ce répertoire rime à rien (a part pour autostart, donc c'est pas forcement interressant comme arborescence).
Pour la partie paquet. Je pense pas que l'élaboration dun gestionnaire de paquet unique soit interressant ou réalisable. Car dans ce cas quid des différentes politiques des distributions ? Je préfère plutot une armonisation dans les paquets. Chacun utilise son gestionnaire de paquet, mais la structure d'un paquet à l'autre est similaire. De ce fait on pourrait reprendre rapidement adapter un paquet d'une distrib en un paquet pour une autre. Mais ce modèle dépend aussi du bien vouloir des développeurs d'application.
Ce système me semblerai d'ailleurs plus facile à réaliser aujourd'hui.
Ce système serait aussi plus indépendant des différentes bibliothèques ( et compilateurs) utilisées. Donc respect du choix des développeurs de distribs.
Pour le manque de paquets de versions dev ou beta, c'est vraie que la réactivité n'est pas la même selon l'application. Pour moi à ce niveau, la seule solution c'est augmenter le nombre de personnes qui assurent le packaging. Peut-être qu'on peut écrire un outils permettant de générer l'ensemble des paquets ?
Et enfin, pour les fichiers de conf, je suis assez d'accord que tout dans la ~ n'est pas forcément le top. Un répertoire .config contenant l'ensemble des fichiers de conf des applis serait un plus (mais pas une base de registre comme il en a été question à une époque).
Voila, désolé pour la longueur mais je trouve le sujet très interressant.
[^] # Re: pas un gestionnaire de paquet identique, mais une structure peut-etr
Posté par B16F4RV4RD1N . Évalué à 2.
après, cela pourrait être un genre de moulinette qui génère automatiquement les paquets en fonction de la distribution (bibliothèques dépendantes etc), comme cela le travail d'empaquetage sera fait seulement une seule fois.
Il existe checkinstall qui fonctionne pas trop mal, mais je pense que cela ne fait pas des paquets super propres, en tout cas cela dépanne très bien pour des installations locales !
http://www.trustonme.net/didactels/117.html
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# FSB
Posté par melalcoolique . Évalué à 1.
L'intégralité de sa réflexion: http://www.markshuttleworth.com/archives/66
[^] # Re: FSB
Posté par lasher . Évalué à 3.
[^] # Re: FSB
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
http://www.markshuttleworth.com/archives/66
http://www.framasoft.net/article624.html#8
http://www.lemondeinformatique.fr/entretiens/lire-mark-shutt(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.