Journal Distributions Linux, vers un éclatement des formats de paquetages ?

Posté par .
Tags : aucun
0
27
oct.
2006
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...
  • # La solution ...

    Posté par . Évalué à 1.

    ... Autopackage !

    http://autopackage.org/
    • [^] # Re: La solution ? Pas vraiment...

      Posté par (page perso) . Évalué à 4.

      # Is autopackage meant to replace RPM?

      No. RPM is good at managing the core software of a distro. It's fast, well understood and supports features like prepatching of sources. What RPM is not good at is non-core packages, ie programs available from the net, from commercial vendors, magazine coverdisks and so on. This is the area that autopackage tackles. Although in theory it'd be possible to build a distro based around it, in reality such a solution would be very suboptimal as we sacrifice speed for flexibility and distro neutrality. For instance, it can take several seconds to verify the presence of all required dependencies, something that RPM can do far quicker.


      http://autopackage.org/faq.html

      Donc non, autopackage n'est pas la solution.
      • [^] # Re: La solution ? Pas vraiment...

        Posté par (page perso) . Évalué à 6.

        Ce n'est pas parce que ce n'est pas LA solution que ce n'est pas UNE solution.

        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 . Évalué à 3.

          Sans déc !?

          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 (page perso) . Évalué à 4.

            Sous Gentoo, emerge ne tient pas seulement compte des dépendances explicites des paquets, il les reconstruit à partir des choix de compilation pour chaque paquet (car ces choix peuvent changer entre 2 appels).
            Et ça, aucun autre gestionnaire de paquets n'est capable de le faire.
          • [^] # Re: La solution ? Pas vraiment...

            Posté par (page perso) . Évalué à 4.

            Tu parles de rapidité du sytème de paquet. Je suppose que tu penses à la vitesse d'installation. Moi ce qui m'importe c'est le temps entre la release d'un projet et sa disponibilité dans le système de paquet. Et là, franchement on est très mauvais.

            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 (page perso) . Évalué à 3.

              Il me semble que les versions beta, ce soit un des buts de "klik" ou autopackage ou 0conf (enfin j'en ai plus entendu parlé pour klik), ce qui en plus de ne pas foutre le bordel avec le paquet correspondant en stable
    • [^] # Re: Une solution ... AUTOPACKAGE

      Posté par . Évalué à 2.

      Pour en remettre une couche.
      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 . Évalué à 3.

        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...

        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 (page perso) . Évalué à 5.

        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...


        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 . Évalué à 1.

          Sous windows, les logiciels tiers sont plus ou moins bien livrés quand même. Essayez d'utiliser correctement votre windows (c'est a dire sans etre admin ni meme user avec pouvoir), et d'un seul coup la quasi totalité des logiciels merdoient. C'est souvent pas grave, des droits a placer sur des clefs de base de registre ou sur un repertoire NTFS, ...
          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 (page perso) . Évalué à -9.

    Il y a plusieurs erreurs, mais la plus grosse (et je ne suis pas allé plus loin) est sans contest :

    "Si j'ai bien compris le format .deb est arrivé le premier (cf. wikipedia à propos du Linux Standard Base), puis .rpm,"


    Tu as mal compris.
    • [^] # Re: Trop d'imprecision tue la reflexion

      Posté par . É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 (page perso) . Évalué à 1.

        Cette phrase que tu me copie veut dire (sauf si on m'a mal appris l'anglais) que les .DEB sont plus anciens que les .RPM. Pas que le ".deb est arrivé le premier".

        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 . Évalué à 3.

          Ca depend du point de vu... Toi tu vois ca de maniere "absolue".

          Einstein disait "tout est relatif"...
        • [^] # Re: Trop d'imprecision tue la reflexion

          Posté par . Évalué à 2.

          je sais, mais il y a 3 formats actuellement : rpm, deb et tgz de slackware. Mais les paquets slackware ne gèrent pas les dépendances (de base), et c'est une archive tgz, aussi, même si c'est arrivé avant (éclaire nous de tes lumières et donne nous plus de précisions...), je ne sais pas si on peut le compter comme le reste.

          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 (page perso) . Évalué à 6.

            Pacman[1] qui est le gestionnaire de ArchLinux et de Frugalware utilise des paquets qui sont en fait de "bêtes" tgz (d'où l'extension, sous Arch: .pkg.tar.gz). Les dépendances sont très bien gérées et la méthode de création de paquet et l'une des plus simples qui existe actuellement (je compare avec les .spec pour les RPMs qui, bien que puissants, sont loin d'être aussi simples à maîtriser qu'un PKGBUILD sous Arch).

            [1] - http://www.archlinux.org/pacman/
            • [^] # Re: Trop d'imprecision tue la reflexion

              Posté par . Évalué à 2.

              Effectivement les paquets Archlinux sont très simple à faire. Par contre je ne sais pas si ça a changé depuis, mais à l'époque où j'étais sous Archlinux les paquets n'étaient pas dutout "splités". Du coup quand on voulais juste une lib (mysql par exemple), on se retrouvais avec le serveur et le client qui vont avec. Ce n'est pas vraiment optimal à mon avis.
              • [^] # Re: Trop d'imprecision tue la reflexion

                Posté par . Évalué à 1.

                Ca n'a jamais été dans la philosophie Slackware de découper un logiciel en binaire, client, serveur, lib, données, docs etc...
                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 (page perso) . Évalué à 4.

                  > Archlinux est parti de la slack ça a dû rester.
                  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 . Évalué à 3.

                  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

                  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 . Évalué à 2.

                    « Tu suppose que tous les utilisateurs touchent un peu à tout. »

                    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 . Évalué à -1.

                    Un autre avantage c est la limitation des trous de sécurité possible, en effet installer tout et n importe quoi alors qu on l en a pas l utilité et dans le cas de serveurs qui tournent ... Donc si je veux juste php je dois forcément me coltiner Apache ?? et Python évidemment je fois me farcir Zope aussi, pas de pb il y a de la place sur le DD enfin ...
                    • [^] # Re: Trop d'imprecision tue la reflexion

                      Posté par . Évalué à 1.

                      Là tu racontes n'importe quoi.

                      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 . Évalué à -1.

                        Je disais ça parce qu à une époque sur une distrib que je ne citerai pas je voulais installer php et direct il m installe php, un autre jour je voulais juste le client postgres bam il m installe le serveur, là tu me cites la debian sans le dire, elle évidemment a tout bien séparé alors que M...diva ... ah mince je l ai dit ^^ allez moinssez moi faites vous plaisir ...
          • [^] # Re: Trop d'imprecision tue la reflexion

            Posté par . Évalué à 3.

            Si on peut tout à fait compter les tgz de Slackware comme un format de paquet à part entière.
            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 . Évalué à 2.

              ok, merci de l'info. Par contre est-ce que c'est arrivé avant les paquets debian ? (juste une question, pas pour relancer une polémique, de toute façon c'est accessoire par rapport au pb soulevé ici)

              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 . Évalué à 3.

              C'est surtout je pense un format de paquet assez primitif, puisque un peu plus fruste qu'un deb ou un rpm.

              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 . Évalué à 0.

                "frustre" ???

                pourquoi pas "orangé" ou "avec un arrière-goût de betterave" ?
              • [^] # Re: Trop d'imprecision tue la reflexion

                Posté par . Évalué à 6.

                Tu sais, finalement un .deb ou .rpm, ce n'est pas grand chose de plus que le .tgz de la slack, c'est un brin plus opaque, ça ressemble à un bidule magique avec plein de merveilles dedans, mais c'est aussi tout un tas de fichiers mis dans une archive, quelques descriptions, des scripts d'installation/désinstallation, et des informations diverses, les dépendances en particulier, qui elles ne sont pas dans les .tgz de la slack mais pourraient y être, ça ne fait qu'un fichier de plus à ajouter, et à gérer aussi.

                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 . Évalué à 3.

                  Je suis d'accord avec toi sur le fait qu'il s'agit d'un choix que d'utiliser un format binaire d'archive qui n'est pas un pur tar : il a été choisi d'intégrer certaines méta-données dans le fichier principal plutôt que d'utiliser un tar et de placer ces méta-données dans un fichier spécial du tar.
                  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 . Évalué à 2.

                    Oui, en effet ^^
                    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 . É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.

                      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 . Évalué à 1.

          RPM et DEB sont plus ou moins nés en même temps

          Les deb datent de mars 1995

          http://fr.wikipedia.org/wiki/Debian

          Et redhat
          Red Hat est également l'inventeur du système de gestion de paquets RPM (Red Hat Package Manager en 1995 avec Red Hat Linux 2.0), repris par la suite par de nombreuses autres distributions, telles que SuSE, Mandriva, ou encore Yellow Dog.


          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 . Évalué à 7.

    Salut,

    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 . É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 (page perso) . Évalué à 2.

        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.


        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 (page perso) . Évalué à 2.

          Ce que vous appelez répertoire "polluant" sont une très bonne idée !

          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 . Évalué à 3.

            non c'est une pollution qui ne convient qu'aux adeptes de windows
            • [^] # Re: Mon avis à moi...

              Posté par . Évalué à 2.

              non c'est une pollution qui ne convient qu'aux adeptes de windows

              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 . Évalué à -1.

                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.

                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 . Évalué à 3.

                  Chapeau l'argumentation, c'est parce que ça vient de windows que c'est mal ? Sachant que sur un Desktop, tout le monde à peu prêt a ces répertoires, pourquoi pas les mettres par défaut ? Ca permet de faire des trucs genre préconfigurer le logiciel de musique, mettres des icones appropriées, ou des choses comme ça, des trucs "user friendly" (le vilain mot). Et si t'es pas content, tu changes ^^.
                  • [^] # Re: Mon avis à moi...

                    Posté par . Évalué à -2.

                    je n'ai pas ce genre de dossier Ok ?
                    je maintien l'apparititonde ce genre de choses a été faites pour pas depayser les windowsiens Ok ?
                    • [^] # Re: Mon avis à moi...

                      Posté par . Évalué à 1.

                      SI tu crois avoir raison en criant plus fort que les autres, libre à toi.
                      • [^] # Re: Mon avis à moi...

                        Posté par . Évalué à -3.

                        bravo
                        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 . Évalué à 1.

                          J'aimes les gens aux idées bien arrêtées et les dialogues de sourds.

                          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 . Évalué à -5.

                            si tu avais le debut d'un comencent d'un argumentation ,mais tu n'en as pas
                            au fait sous windows déja je n'aimais pas
                            • [^] # Re: Mon avis à moi...

                              Posté par . Évalué à 4.

                              Mais... je ne vois pas pourquoi on se prend la tête là :

                              _ 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 . Évalué à 3.

                                _ 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...)

                                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 . Évalué à 2.

                                  Chez moi il n'y sont pas ces répertoires (A pars Desktop bien sur) J'utilise KDE 3.5.5 sous Gentoo, donc je pense que c'est spécifiques a certaines distribs grand public.

                                  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 (page perso) . Évalué à 1.

                                    Et si tu refaisais les liens(ou remonter dans ces repertoires ou que sais-je encore) pour pointer vers ces répertoires, ca te génerait toujours autant ?
                                    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 . Évalué à 2.

                                  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.

                                  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 (page perso) . Évalué à 6.

                                    C'est mandriva qui ajoute ces répertoire personnalisé, enfin faut pas pousser, tu peux les supprimer facilement.

                                    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 (page perso) . Évalué à 7.

                                  Ya pas que dans ton home que tu devrais faire le ménage si tu veux gagner de la place.

                                  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 . Évalué à 1.

                                    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 !!

                                    Mais ce qui est dans /proc est virtuel, non ?
                    • [^] # Re: Mon avis à moi...

                      Posté par (page perso) . Évalué à 10.

                      Et l'apparition des bureaux virtuels sous Windows et Mac OS X, c'est pour pas dépayser les linuxiens ?
                  • [^] # Re: Mon avis à moi...

                    Posté par (page perso) . Évalué à 1.

                    Sachant que sur un Desktop, tout le monde à peu prêt a ces répertoires, pourquoi pas les mettres par défaut ?
                    Beh dans mon boulot, tout le monde l'a mais personne ne s'en sert : autant le virer.
          • [^] # Re: Mon avis à moi...

            Posté par . Évalué à 2.

            En fait, en y réfléchissant bien, il y a un truc qui m'a toujours plus ou moins gêné : le répertoire "Mail" de KMail dans ~.

            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 (page perso) . Évalué à 1.

              Ben si chaque appli de mail devrait se mettre dans ~/Mail, vu que c'est une "norme" :) (kmail y rajoute un .desktop ou quelque chose du genre, mais rien de bien encombrant)
              • [^] # Re: Mon avis à moi...

                Posté par (page perso) . Évalué à 2.

                Et j'ai même configuré sylpheed-claws pour utiliser ce même dossier ~/Mail
                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 . Évalué à 4.

        oui tout à fait pour ~/.etc . Mais il me semble que freedesktop préconise ~/.config

        à propos de :
        Un programme utilise des librairies, et toutes les distrib n'ont pas les mêmes. (version, etc...)


        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 . Évalué à 3.

          Je viens de regarder, et justement, Xfce4 place ses fichiers de configuration dans ~/.config. Il me semble que c'est assez récent. C'est le seul programme à faire ça sur ma machine.

          --
          http://www.tessier-net.org
          • [^] # Re: Mon avis à moi...

            Posté par . Évalué à 4.

            Xfce respecte cette norme FreeDesktop depuis Janvier 2005, avec la sortie de Xfce 4.2.0. Avant, les fichiers de conf étaient dans .xfce4/, équivalent du .kde/ ou du .gnome2/ .

            Voir ici pour plus d'infos : http://www.foo-projects.org/~benny/xfce/file-locations.html
          • [^] # Re: Mon avis à moi...

            Posté par . Évalué à 2.

            Rox fait pareil, ainsi que Graveman, GCfilms, Tea.
            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 (page perso) . Évalué à 3.

        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.
        Allez, un petit cadeau pour toi : http://ordiluc.net/fs/libetc/
    • [^] # Re: Mon avis à moi...

      Posté par . Évalué à 3.

      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).


      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 . Évalué à 2.

        Smart ? je vais me renseigner...

        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 . Évalué à 2.

          Je n'ai jamais utilisé Adept ou Synaptic, donc je ne peux pas te dire ;)

          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 (page perso) . Évalué à 9.

      Pour les fichier caché, où veux-tu les mettre ?


      /usr/dtc, clairement.
  • # Normal

    Posté par (page perso) . Évalué à 10.

    C'est parce que c'est libre.

    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 . Évalué à 3.

      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 ?

      C'est déjà le cas ! emacs et ion [ça sert à quoi déjà le desktop manager ?].
      • [^] # Re: Normal

        Posté par . Évalué à 5.

        Pourquoi ion alors qu'on peut déja splitter l'écran dans tous les sens avec emacs ? Ca fait double emploi !
    • [^] # Re: Normal

      Posté par . Évalué à 2.

      non, je ne veux pas du .deb pour tout le monde, mais cela serait pas mal si les distributions pouvaient s'entendre un peu mieux pour faire un genre de consensus qui faciliterait la vie, et (ma dernière remarque n'était pas anodine), donnerait un peu plus de crédit à linux peut être.

      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 . Évalué à 6.

        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.

        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 (page perso) . Évalué à 2.

          Sur Mac OS X, il y a quand même le Ctrl-clic qui fait office de bouton droit.

          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 . Évalué à 0.

      > Ca peut paraitre triste, mais c'est ça aussi la liberté.

      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 (page perso) . Évalué à 3.

        une majorité de personnes pour se mettre d'accord et definir une norme
        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 (page perso) . Évalué à 1.

      Pour unifier ce qui peut l'être, la solution est d'inviter tous les acteurs aux prochaines RMLL et de les faire travailler ensemble.
      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 (page perso) . Évalué à 10.

    En tant que développeur de Logiciel Libre je suis aussi confronté au problème de packaging. J'en suis aussi arrivé à la conclusion que c'est aujourd'hui notre principale lacune pour faire venir des non informaticiens sur GNU/Linux.

    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 . Évalué à 2.

      - urpmi devait le faire (User RPM Install) mais des adminsys aurait eu peur que leur employé install n'importe quoi

      - 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 . Évalué à 1.

        Si je me souviens bien, le principe de klik, c'est :
        -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 (page perso) . Évalué à 1.

        C'est vrai que sous windows ça peut tourner à la catastrophe mais sous GNU/Linux c'est la catastrophe pour les utilisateurs de ne pas pouvoir installer les logiciels dont ils ont besoin.

        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 . Évalué à 1.

        oui, klik fonctionne pas mal, je ne l'ai pas évoqué :

        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 (page perso) . Évalué à 3.

          Je suis sous Ubuntu Dapper et j'avais envie de tester Abiword mais la version dans les dépots est un peu ancienne et elle gère moins bien le format OpenDocument.
          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 . Évalué à 2.

            oui tout à fait.
            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 (page perso) . Évalué à -3.

      Installer un logiciel sur un système en tant qu'utilisateur normal.

      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 (page perso) . Évalué à 3.

        Pour des raisons évidentes de sécurité et stabilité, heureusement que c'est impossible !


        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 (page perso) . Évalué à 1.

          Je pense que tu prend une partie du problème par le mauvais bout.
          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 . Évalué à 1.

            je pense qu'il voulait dire qu'un utilisateur pourrait installer un paquet dans son dossier personnel, mais avec la facilité des outils de gestion de paquets, quelque chose comme "apt-get install nom_du_paquet --prefix=$HOME" (ça n'existe pas (encore ?), c'est un exemple en comparaison à "./configure --prefix=$HOME"), l'utilisateur peut l'installer uniquement là où il peut écrire (i.e. son dossier personnel), mais avec gestion de dépendances, scripts d'installs, etc...
            • [^] # Re: Les limites du système de packaging actuel

              Posté par . Évalué à 2.

              C'est possible sous slack :
              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 . Évalué à 0.

          En fait, ce qui est dangereux, c'est que le programme d'installation face des choses qui pourraient potentiellement casser ton système (installation d'un service, modification de programme, bibliothèques, etc). En mettant ton programme dans le /home, tu n'autorise l'installeur (quel qu'il soit) à ne toucher qu'aux fichiers du répertoire home.

          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 (page perso) . Évalué à 2.

        Pour une raison évidente de praticité et de contrôle de son compte utilisateur, heureusement que c'est possible.

        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 en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

    • [^] # Re: Les limites du système de packaging actuel

      Posté par . Évalué à 2.

      - 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).


      Les installateurs de type Adept ou Synaptic demandent juste un mot de passe, ça n'est pas très compliqué.

      - 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).


      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 (page perso) . Évalué à 0.

        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.


        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 . Évalué à 2.

      - Installer la version N-1, N+1 d'un logiciel. Non monsieur, vous devez utiliser celui qui est livré avec votre distribution.

      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 . Évalué à 2.

      - 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.
      (...)
      Ç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 (page perso) . Évalué à 1.

        Pourquoi ne pas distribuer des versions binaires liées statiquement ?

        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 (page perso) . Évalué à 2.

        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.


        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 . Évalué à 7.

      > Installer la version N-1, N+1 d'un logiciel.Non monsieur, vous devez utiliser celui qui est livré avec votre distribution.
      > [...]
      > Ç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 . Évalué à 7.

    Il faudrait surtout un système de paquet pour logiciel proprio. De préférence, un système qui n'utilise pas root pour éviter de risquer de pourrir son système.

    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é"

  • # La conscience libre commune l'a fait exprès

    Posté par . Évalué à 1.

    Bin oui, car j'ai l'impression que ces multiples versions de packaging permette d'obliger les entreprises à livrer les sources : car on l'a vu mainte et mainte fois, les pakages de binaire unique genre Red Hat old school ça doit faire exploser la boite mail du support :-)

    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 (page perso) . Évalué à 2.

      Oui, c'est vrai qu'à part opera, je ne connais pas de logiciels propriétaires qui proposent des paqhets pour tant de distributions (il y a une quinzaine de distributions proposées et plusieurs paquets possibles suivant la version de la distrib en question, au total, il doit bien y avoir plus de 50 paquets différents différents proposés...)
      • [^] # Re: La conscience libre commune l'a fait exprès

        Posté par . Évalué à 3.

        Opera a un intérêt certain à montrer qu'il tourne partout, son marché actuel étant l'embarqué, téléphones et autres consoles...
      • [^] # Re: La conscience libre commune l'a fait exprès

        Posté par (page perso) . Évalué à 2.

        Il n'y a pourtant pas tant de distributions majeures que cela.
        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 (page perso) . Évalué à 1.

    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)


    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 (page perso) . Évalué à 2.

    J'ai lu avec beaucoup d'interet ce journal. Je partage certains point, d'autre me gènes plus.
    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 . Évalué à 2.

      oui, voilà, je pense tout à fait ainsi :

      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.


      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 . Évalué à 1.

    Mark Shuttleworth a posté aujourd'hui au sujet de la grande quantité de systèmes de paquets disponibles sous GNU/Linux

    Today, these differences are just a hindrance. The fact that there are so many divergent packaging systems in the free software world (and I include the various *bsd’s) is a waste of time and energy. We want to focus the collective brainpower of the community on features and bugs, not on packaging. I would like to see the LSB renamed to the FSB - the “Free Software Base”, and get buy-in from the *BSD’s, and then I’d like to see us define distribution-neutral packaging that suits both the source-heads and the distro-heads.


    L'intégralité de sa réflexion: http://www.markshuttleworth.com/archives/66

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.