Sondage Qu'utilisez vous pour l'installation de vos logiciels tiers ?

Posté par .
Tags : aucun
1
1
juin
2012
  • rpm, le même que pour le système :
    335
    (14.0 %)
  • deb, le même que pour le système :
    1259
    (52.7 %)
  • slp, Stampede Linux Packages :
    0
    (0.0 %)
  • autopackage, en plus de celui pour le système :
    13
    (0.5 %)
  • 0install, en plus de celui pour le système :
    2
    (0.1 %)
  • Glick2, en plus de celui pour le système :
    1
    (0.0 %)
  • sources avec scripts du distributeur :
    179
    (7.5 %)
  • sources uniquement :
    156
    (6.5 %)
  • les postes y accèdent par autofs.. :
    5
    (0.2 %)
  • J'ai tout converti en apk ! :
    22
    (0.9 %)
  • La khabââle existe... LinuxFr.org a encore oublié de mettre les bons choix dans ce sondage :
    417
    (17.5 %)

Total : 2389 votes

La liste des options proposées est volontairement limitée : tout l'intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées, ou de l'impossibilité de choisir plusieurs réponses. 76,78% des sondés estiment que ces sondages sont ineptes.
  • # Pacman + makepkg

    Posté par (page perso) . Évalué à 10. Dernière modification le 01/06/12 à 12:58.

    makepkg pour construire le package, et Pacman pour l'installer comme il faut.
    On pourrait dire, depuis les sources, puis écrire le PKGBUILD (script pour créer le package via makepkg).

  • # On package :)

    Posté par . Évalué à 1. Dernière modification le 01/06/12 à 13:34.

    C'est souvent la compilation classique qui se retrouve dans /usr/local ou autre. Ou alors, je piques les srpms de Fedora et je les recompiles (en tweakant un peu si besoin). Sinon, je fais le paquet.

  • # Et le format tgz ...

    Posté par . Évalué à 3.

    facile à construire à partir d'un script facilement compréhensible et adaptable à souhait ?

    • [^] # Re: Et le format tgz ...

      Posté par . Évalué à 2.

      Tu n'es pas passé au txz ?

      • [^] # Re: Et le format tgz ...

        Posté par . Évalué à 2.

        Ce serait une erreur, s'il génère ses paquets, ou veut les "retravailler" sur autre chose que du Linux.

        Ca m'est bien souvent arrivé de bloquer sur ce genre de détail stupide : un paquet quelconque à récupérer, décompresser, fire 2 ou 3 modifs et recompresser pour installation, et je n'ai pas pu le faire à cause de ces stupides formats linux_only.

        • [^] # Re: Et le format tgz ...

          Posté par . Évalué à 4.

          Il me semble que le txz, c'est parfaitement standard…
          On passe juste de la compression gzip à la compression xz…

          • [^] # Re: Et le format tgz ...

            Posté par . Évalué à 2.

            Je ne suis pas sur que ce soi sur le txz que j'ai eu le problème, mais je ne suis pas certain de trouer du xz natif sur du Solaris ou du HP-UX.

            • [^] # Re: Et le format tgz ...

              Posté par . Évalué à 2.

              Dommage mauvais exemple :

              http://www.opencsw.org/packages/xz/
              http://hpux.connect.org.uk/hppd/hpux/Misc/xz-5.0.3/

              Et en fait le site officiel donne une liste de systèmes supportés :

              http://tukaani.org/xz/

              Donc en quoi c'est une mauvaise idée ? C'est pas supporté par défaut (Windows ne gère pas par défaut gzip)

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Et le format tgz ...

                Posté par . Évalué à 2.

                Dommage mauvais exemple :

                http://www.opencsw.org/packages/xz/
                http://hpux.connect.org.uk/hppd/hpux/Misc/xz-5.0.3/

                Il a bien précisé « natif ». Là, tu nous donnes des sites tiers.

                Au passage, au moins pour le deuxième, les paquets s'installent dans /usr/local qui par défaut n'est pas dans $PATH sur HP-UX. Donc en plus d'installer des paquets non-officiels, tu dois modifier ta configuration pour les utiliser.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Et le format tgz ...

                  Posté par . Évalué à 3.

                  Il a bien précisé « natif ». Là, tu nous donnes des sites tiers.

                  Donc tu voulais dire inclus en standard ?

                  tgz n'est pas en « natif » sous windows (un peu plus utilisé que solaris et hp-ux) donc il vaudrais mieux utiliser autre chose comme format je pense (peut être zip ?).

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Et le format tgz ...

                    Posté par . Évalué à 2.

                    Donc tu voulais dire inclus en standard ?

                    Oui. Gzip l'est sur tous les Unices.

                    tgz n'est pas en « natif » sous windows

                    Quoi Windows ? Il est posix maintenant ?

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Et le format tgz ...

                      Posté par . Évalué à 1.

                      Quoi Windows ? Il est posix maintenant ?

                      Partiellement oui. Linux aussi l'es partiellement (mais moins).

                      Et puis sortir l'excuse POSIX quand utilise dans la majorité des cas des extensions GNU (comme l'histoire des bashismes avec dash). Ça fait longtemps qu'on dis que POSIX est un peu vieux, une mise à jour pourrait être intéressante (pax à la place de tar ça ne ferais pas de mal par exemple).

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Et le format tgz ...

                    Posté par . Évalué à 3.

                    M'en fiche de Windows. Il me viendrait pas à l'idée de trifouiller un package Unix et modifier une conf de ce package sous Windows.

  • # Checkinstall

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

    Je fais des deb avec checkinstall.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Pourquoi Linux ne décolle pas

    Posté par . Évalué à -5.

    C'est marrant, ce sondage montre clairement pourquoi Linux ne perce pas dans le grand public!
    Les 2 bonnes réponses sont:
    - Je lance l'installeur que j'ai trouvé sur le site de l'application,
    - Je la cherche et l'installe depuis le market.
    Et heu… Ah ben non, ces 2 réponses ne sont pas dispo :-)

    • [^] # Re: Pourquoi Linux ne décolle pas

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

      • Je lance l'installeur que j'ai trouvé sur le site de l'application,

      Si : autopackage (qui s'appelle plutôt listaller aujourd'hui), 0install ou Glick2. S'ils utilisent autre chose c'est qu'ils souffrent de NIH.

      • Je la cherche et l'installe depuis le market.

      Relis le titre du sondage : « Qu'utilisez vous pour l'installation de vos logiciels tiers ? » Dans ce contexte, « tiers » signifie : non disponible dans les dépôts de votre distribution.

      • [^] # Re: Pourquoi Linux ne décolle pas

        Posté par . Évalué à 0.

        Il faut arrêter d'être aveugle, les autopackages ça n'est qu'un système de plus, qui participe à la fragmentation. Certaines distributions permettent de l'utiliser, d'autres pas. Certaines applis l'utilisent, d'autres pas…

        Quand aux repository des distributions j'ai très bien lu merci, le problème est justement que les applications tierces ne sont pas disponibles dans un endroit centralisé. Le market Android ne contient pas que les applications google.

        • [^] # Re: Pourquoi Linux ne décolle pas

          Posté par . Évalué à 4.

          Quant aux repository des distributions j'ai très bien lu merci, le problème est justement que les applications tierces ne sont pas disponibles dans un endroit centralisé. Le market Android ne contient pas que les applications google.

          Ce n'est pas tout à fait vrai: les systèmes de gestion de packages maintstream permettent d'ajouter les dépôts d'un éditeur, ce qui est encore mieux que les markets puisque ce sont des markets multi-sources.
          Par exemple Adobe (dont il n'y a pourtant pas que du bien à dire) fournit Flash en rpm dans un dépôt yum, et fournit même le rpm pour installer le dépôt yum. Du coup il s'intègre parfaitement à yum, qui est en fait le Fedora Market et le RedHat Store.
          Quand tu fais ton "yum upgrade" périodique, de temps en temps Flash se met à jour tout seul.

        • [^] # Re: Pourquoi Linux ne décolle pas

          Posté par . Évalué à 1. Dernière modification le 01/06/12 à 23:28.

          à propos d'arrêter d'être aveugle, on peut aussi regarder le contexte, et voir s'il n'y a pas du sens à utiliser un système comme autopackage, ou tout autre du même type, parfois , non ?

          par exemple le packaging rpm, tel qu'il est réalisé par les distros, ,e laisse aucun choix à l'utilisateur. Rien, nada, nib. Cela a bien été tenté mais le relais assuré par les gui n'ont pas suivis. Elles ne suivent même pas pour la gestion des rpmnew. La situation est différente chez Debian où au contraire le packaging pose souvent des questions à l'utilisateur, et lui laisse de nombreux choix. Ne connaissant pas assez Debian, je ne sais pas si du côté des gui ça suit, ou pas.

          Il me semble qu'il s'agit là d'un contexte intéressant pour utiliser un système ala autopackage : permettre à l'utilisateur de décider des choix primaires concernant ce logiciel. Ce n'est pas ce que l'on retient en premier, préférant parler de la qualité du packaging lui même, de la maintenance de l'outil, de l'intégration dans la distribution et des problèmes de mises à jour. Tout ceci existe aussi avec autopackage ou autre, de manière et à des variations différentes.

          Ce qui n'empêche pas de pouvoir trouver bien sympa d'avoir le choix à l'installation que audio-projet ne créait pas un dossier à la racine du home, à l'identique pour Eclipse, ou bien pour Kdenlive, la liste risque d'être longue… L'intégration se pose aussi, et il est possible que cela soit intéressant de laisser l'utilisateur choisir de placer ce type de dossier de travail en se servant de l'arbo xdg, par exemple, en deux clicks dans un selecteur/navigateur de fichiers/dossiers.

          Des avantages, il y en a d'autres, mais qui ne prennent leur sens que si telle ou telle solution était adoptée par plus de projets.

          • [^] # Re: Pourquoi Linux ne décolle pas

            Posté par . Évalué à 2.

            Si je me souviens bien, les questions sous deb ne dépend pas de l'installateur (aptitude, synaptic, …) mais des scripts de pre/post_install.

            Une syntaxe particulière est utilisé pour que ce soit cohérent entre les != paquets (même commande utilisé partout).
            La présentation dépend des options ensuites (mode X par exemple, ou mode texte uniquement).

        • [^] # Re: Pourquoi Linux ne décolle pas

          Posté par . Évalué à 1.

          Pour la partie suite les dépôts, pour Google Chrome, tu peux télécharger un deb, qui va installer le logiciel et ajouter le dépôt qui va bien. Du coup installer Chrome sous Debian, c'est :

          • télécharger le deb proposé sur le site officiel
          • double cliquer sur le fichier, gedebi se lance
          • cliquer sur installer
          • entrer le mot de passe
          • fermer gedebi

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Pourquoi Linux ne décolle pas

          Posté par . Évalué à 2.

          Quand aux repository des distributions j'ai très bien lu merci, le problème
          est justement que les applications tierces ne sont pas disponibles dans un endroit
          centralisé.

          Canonical propose quand même des applications tierces commerciales, gratuites ou payantes, sur son "Ubuntu Software Centre".

          N'importe qui peut rajouter une appli commerciale, du moment qu'elle répond à un minimum de critères de qualité de packaging (p.e. usage du répertoire /opt).

          Malheureusement, le succès à été moindre que ce qu'on aurait pu espérer.

        • [^] # Re: Pourquoi Linux ne décolle pas

          Posté par . Évalué à 4.

          Quand aux repository des distributions j'ai très bien lu merci, le problème est justement que les applications tierces ne sont pas disponibles dans un endroit centralisé. Le market Android ne contient pas que les applications google.

          Les repository sont des markets. Si les "tiers" en question ne les utilisent pas, c'est qu'ils ne veulent pas le faire. Il n'y a aucune différence avec un market android ou un apple store.

          • [^] # Re: Pourquoi Linux ne décolle pas

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

            Il y a une toute petite contrainte : le temps.

            Faire un packet Gentoo, Ubuntu, Slackware, Suse ça prend 4 fois plus de temps que de faire un seul package.

            Après, dur de faire un market unique vu les objectifs de chacun (quoique, créer un truc qui automatise la création des packages, avec ou sans options paramétrables, ça serait chouette)

    • [^] # Re: Pourquoi Linux ne décolle pas

      Posté par . Évalué à 1.

      Pour les appli commerciales comme Opera, il est assez facile de télécharger le paquetage pour sa distro.

      Il est sûr que les choses seraient plus simples s'il y avait moins de formats de paquetages.

      Par exemple, DEB et RPM sont tous les deux très proches en fonctionnalités. Même si j'ai une petite préférence pour DEB, je crois qu'il faudrait mieux que n'importe quel des deux formats soit utilisé par un max de distro, plutôt que la situation actuelle.

      • [^] # Re: Pourquoi Linux ne décolle pas

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

        Le problème, ce n'est pas que le format de paquet (sinon, faire un soft qui les génèrent tous ne serait pas trop compliqué, il y a déjà alien qui fait une partie du boulot), c'est surtout qu'il faut la bonne ABI et c'est relativement difficile d'avoir un truc constant entre les distro dès qu'on sort du noyau.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Pourquoi Linux ne décolle pas

          Posté par . Évalué à 3.

          On peut s'en tirer en se restreignant aux bibliothèques maintenant une bonne interface binaire.

          Fiable:
          GLIBC
          GTK 2.X et associés: GDK, GLIB, pango, cairo.
          libGL
          libX11
          libexif
          libz

          À éviter:
          libpng
          libjpeg (ces derniers temps)
          libexo
          HAL / udisk
          Et beaucoup d'autres librairies…

          Actuellement, je travaille sur la suppression des dépendances peu fiables de Thunar. Je suis arrivé à faire un binaire qui fonctionne sous CentOS 5.x, Fedora 15, OpenSUSE 11, Linux Mint 11.

          • [^] # Re: Pourquoi Linux ne décolle pas

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

            C'est dommage, il n'y a rien pour le son dans ta liste.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Pourquoi Linux ne décolle pas

              Posté par . Évalué à 1. Dernière modification le 03/06/12 à 12:00.

              Rajoutons:

              Fiable:
              ALSA (mais pas bien documenté)
              OSS

              Pas fiable:
              ESD
              arTsd
              JACK
              Phonon?

              Pour le futur?
              PulseAudio?

              • [^] # Re: Pourquoi Linux ne décolle pas

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

                Mais compiler en statique pour Alsa ne pose pas de problème sur les système Pulseaudio ?

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Pourquoi Linux ne décolle pas

                  Posté par . Évalué à 2.

                  L'interface binaire d'alsa-lib est suffisamment stable pour que l'on puisse lier dynamiquement à libasound.so.2 (de toute façon, cette librairie n'est pas conçue pour le lien statique, puisqu'elle charge dynamiquement des modules).
                  Ensuite un système avec PulseAudio a une émulation ALSA, permettant à toutes les applications ALSA de fonctionner en même temps que des applications PulseAudio.

                  Encore mieux, PulseAudio permet même d'émuler, via un démon utilisant l'interface CUSE (Character device in User Space) du noyau, l'interface OSS, pour les programmes faisant des accès direct OSS à /dev/dsp.

                  • [^] # Re: Pourquoi Linux ne décolle pas

                    Posté par . Évalué à 1.

                    Petit détail: Il faut que l'application soit lié à alsa-lib pour bénéficier du module de compatibilité avec pulseaudio. Si on utilise l'inteface ALSA du noyau directement, alors on ne peut pas utiliser pulseaudio en même temps.

        • [^] # Re: Pourquoi Linux ne décolle pas

          Posté par . Évalué à 2.

          ++
          J'ai envie de troller que c'est un problème de marketting.
          Et l'option prends peut être plus de sens encore au moment ou apple et microsoft vont se mettrese mettent à faire des «markets pour isv». Que l'on pinaille sur les styles et les bonnes pratiques, par distro, de faire un spec, ne change rien en fait, non plus ; pas plus que de savoir s'il ne faut pas lacher du lest sur des biblio ou autre question du même accabit. Ce sont probalement des questions intéressantes, mais ce n'est pas le même sujet exactement. D'une manière plus globale, le packaging lui même peut ne pas bouger.
          Gnu a des années d'avance sur microsoft et apple dans ce domaine, et au moment où ces deux là peinent à réaliser leur système, il n'est pas fou de se dire que c'est possible de reprendre de l'avance. Et redonner des choix à l'utilisateur est certainement une méthode sympathique et intéressante, surtout qu'à côté c'est plutôt le mouvement inverse.
          Rpm et dpkg possèdent déjà tout les atouts pour ça, et encore je ne connais pas 50% de l'usage réel de rpm, très probablement…

          Est il si fou de poser des questions, optionnelles, à l'utilisateur, sur au moins les chemins des dossiers tiers ? Est il fou d'imaginer qu'un clickodrome puisse proposer de chrooter ? Est il fou de penser qu'il serait possible avec une gui d'utiliser libvirt-sandbox en choix d'installation ? Il me semble que non, ce sont des opérations que la plupart d'entre nous font sans difficultés et qui relève de la simple gestion de son ordinateur personnel, de simples aides. Et pourtant certains utilisateurs seraient sur le cul de voir ça en gui.

          À la fois le packaging classique, sans qu'il bouge d'un poil, et des gui donnant des choix intéressants voir impressive aux utilisateurs.

          Mes deux cents, avec trois exemples alacon.

      • [^] # Re: Pourquoi Linux ne décolle pas

        Posté par . Évalué à 1.

        On n'est pas près d'en sortir, parce que le prochain format de paquet ou d'installeur qui se prétendra "universel", pour remplacer tous les autres, sera en fait un format de plus qui va empirer le problème…

    • [^] # Re: Pourquoi Linux ne décolle pas

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

      C'est marrant, ce sondage montre clairement pourquoi Linux ne perce pas dans le grand public!

      Il faudrait une sondage supplémentaire pour demander aux gens comment ils font désinstaller un logiciel, avec une réponse spéciale «je formate mon HD et réinstalle Windows» — parceque parfois il n'y a pas d'autre choix!

  • # Gentoo ebuild

    Posté par . Évalué à 5.

    Quand je suis sous Gentoo:
    Gentoo ebuild quand il est disponible, sinon, la tarball d'origine, compilée à la main.
    Quand je suis sous CentOS:
    RPM quand ça marche, SRPM si disponible, tarball d'origine sinon.

  • # Pacman/Yaourt

    Posté par . Évalué à 2.

    Pacman/Yaourt sous Arch oeuf course !

    • [^] # Re: Pacman/Yaourt

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

      Pour moi c'est yaourt tout seul. C'est meilleur et le transit des paquets d'une version à une autre se fait mieux.

      \_o<

      • [^] # Re: Pacman/Yaourt

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

        La fibre, yaourt, et hop un bien meilleur transit.

      • [^] # Re: Pacman/Yaourt

        Posté par . Évalué à 0.

        Yaourt n'est qu'un wrapper à Pacman et à makepkg, avec quelques autres fonctionnalités en plus. Le transit des paquets d'une version à une autre est donc la même qu'avec un paquet compilé par makepkg et installé avec pacman -U.

        J'utilise aussi makepkg et pacman pour installer des paquets tiers, dont les PKGBUILD(s) sont déjà disponibles dans AUR ou par la commande ABS le plus souvent.
        C'est simple et propre.

  • # Commentaire supprimé

    Posté par . Évalué à 2.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: setup.exe

      Posté par (page perso) . Évalué à 10. Dernière modification le 02/06/12 à 13:22.

      Pour le coup, ça revient à extraire une archive dans /bin (ou dans /usr/bin, puisque depuis Windows Vista, les répertoires systèmes sont davantage surveillés).

      setup.exe : pas de gestion des dépendances, un message parfois «tiens je vais t'installer DirectX / Dotnet , je ne sais pas si tu les as, tu pourrais me le dire ? Sinon je t'installe une version qui écrasera peut être ta version plus récente».

      Il faut dire que ce n'est pas facile de se ménager une place dans un écosystème où chaque logiciel commence par vérifier:
      - qu'il n'y a pas un débugger en mémoire
      - que la connexion internet est active pour vérifier qu'on a bien rentré sa clé.
      - que les binaires n'ont pas été modifiés (de préférence en plein milieu de l'exécution, ce n'est pas pour éviter les virus, c'est pour punir les pirates).
      - qu'on a bien plombé la base de registres à coup de GUID, lors de la troisième inscription d'un objet COM qui de toutes façons ne sert plus.

      tout en choisissant avec soin une certaine version du runtime parmi les 50 versions du runtime MSVC (vu qu'on n'a pas les sources et qu'on ne peut pas recompiler).

      Moi aussi je suis bluffé toutes les semaines par la stabilité du foutoir.
      Ils ont mis de la colle sur le chateau de cartes, c'est pas possible, il y a un truc !

  • # Intégriste de la distro

    Posté par . Évalué à 10.

    Si c'est pas dans les dépôts, j'installe pas.

    Vivable sous Debian (en usage perso), beaucoup moins au boulot (CentOS..)

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # ebuild

    Posté par . Évalué à 4.

    Je suis sous Gentoo et si je trouve pas d'ebuild j'en fais un !

    Pareil sous CentOS, si je trouve pas bonheur sur un des dépôts de confiance, EPEL, Mike, dépôt du site officiel du projet (les rpm de nginx qu'on trouve sur le site de nginx sont très bons, ils de dépendent pas de X…), etc., je fait un rpm à mon goût moi-même.

    • [^] # Re: ebuild

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

      +1 pour Gentoo,

      Si un paquet utilise un système standard (autotool,CMake, etc.), c'est du quasi copier-coller de faire un ebuild

  • # slackbuilds.org

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

    Pour les slackeux, Slackbuilds.org propose une large logithèque (source + slackbuild) qui couvre 99% des besoins génériques.
    Allié avec sbopkg (sbopkg.org), on approche la perfection (non, je ne veux pas de résolution automatique de dépendances).

    Pour le reste, la compilation depuis les sources et makepkg font l'affaire.

  • # Je glisse à la souris le répertoire .app vers le disque dur

    Posté par . Évalué à 1.

    C'est la procédure d'installation standard sur Mac OS X.
    Mac OS X, le seul Unix ou .so signifie unshared object.

  • # apt, pkgsrc, stow

    Posté par . Évalué à 5.

    J'installe ça à coup de apt.

    Quand celui ci n'est pas disponible, il y a encore une chance qu'il soit dans http://pkgsrc.org.

    Enfin, en dernier recours, ./configure; make; make install; Mais pas sans avoir changé le prefix pour utiliser http://www.gnu.org/software/stow/ et avoir ainsi tout installé dans /usr/local/stow/logiciel et les liens qui vont bien ( /usr/local/bin etc) gérés par Stow.

  • # slp!?

    Posté par . Évalué à 3.

    Euh, dites-moi tout: Stampede Linux, c'est bien la distro optimisée pour être rapide qui a été effectivement abandonnée plus rapidement que presque toutes les autres?

    Le format a-t-il jamais été utilisé par quiconque d'externe au projet?? J'en aurais mis d'autres avant quand même!

  • # Manque ABS

    Posté par . Évalué à 2.

    Il manque Arch Build System, et le dépôt AUR, car il s'agit bien d'un dépôt de "logiciels tiers", même si la définitions du terme est assez floue à mon sens.
    Dans une distribution linux, quasiment tout les logiciels sont des logiciels tiers…

  • # DIY rpm of course

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

    cd ~/rpmbuild
    (cd SOURCES;wget truc.tar.7z)
    cd SPECS
    vim truc.spec
    rpmbuild --sign -ba truc.spec
    UpdateMyRepos.sh
    rpm -Uvh ../RPMS/*/truc.rpm

    Et si ça me plait plus: rpm -ev truc.rpm

Suivre le flux des commentaires

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