Journal La première distribution majeure !

Posté par  .
Étiquettes :
41
22
juil.
2011

Sommaire

Et oui, depuis le 16 juillet, cela fait 18 ans que Patrick Volkerding a réalisé la version 1.0 de la Slackware, la plus vieille distribution encore maintenue de nos jours. Je sais bien que je suis à la bourre, mais mieux vaut tard que jamais. Au-début je voulais m'arrêter là, mais comme ceci est mon premier journal j'ai développé un peu (désolé aux familles …).

Quelques points forts de cette distribution qui expliquent que malgré son âge avancé (en temps informatique) elle a toujours autant de succès et est toujours dans le top 10 de distrowatch.

Sa philosophie peut être résumée en KISS (Keep it simple, Stupid!) qui vise à éliminer toute complexité non nécessaire.

Ici, pas de pam, pulseaudio, systemd ou autre gadget. Un logiciel est incorporé dans la distribution que lorsqu'il marche et s'il apporte vraiment quelque chose. Il n'y a pas non plus de date de sortie imposée par des problèmes de marketing et elle sort quand elle est prête (mais plus souvent que Debian).
D'une version à l'autre, l'administrateur n'est pas dépaysé par les nouveautés qu'il n'a pas demandé.

Une forte personnification via son créateur et mainteneur principal.

En effet, on ne peut pas vraiment comprendre son histoire sans parler du grand gourou Patrick Volkerding ou Pat. C'est lui qui pendant longtemps a été le seul maître à bord, même si comme dit lors de la sortie de la version 13.1 il y a maintenant plus de gens qui participent.

Slackware est aussi une distribution qui ne se prend pas la tête et qui a su rester jeune.

Dès sa création, le nom choisit est dérivé de Slack, le St Graal de la secte Church of the Subgenius. Ensuite, alors qu'il y avait une escalade de la numération entre les distributions, Pat décide de passer de la version 4 à la version 7 pour se moquer de cette course (quand est-ce que lynx passe de la version 2.8 à la version 11?). Finalement, la dernière réalisée est la 13.37 soit leet.

Un bon gestionnaire de paquets.

KISS est aussi appliqué au gestionnaire de paquet. C'est le seul gestionnaire de paquet qui assure grave depuis 18 ans! Il s'occupe d'installer et de désinstaller les paquets de manière simple et efficace à partir d'une source locale :

installpkg nom.t?z pour installer un paquet
removepkg nom.t?z pour le désinstaller
upgradepkg nom.t?z pour le mettre à jour

Comme ses utilisateurs se font vieux, il existe maintenant pour les feignants slackpkg qui permet d'installer/désinstaller/… à partir d'un dépôt distant :

slackpkg install nom
slackpkg remove nom
slackpkg upgrade nom
slackpkg upgrade-all pour mettre à jour toute la distribution

Pendant ce temps, voyons ce que fait la concurrence d'après la doc :
Sous Debian il y a d'après la FAQ dpkg < apt < aptitude < synaptic et tasksel, mais la FAQ n'explique pas comment utiliser ce dernier. Et si ce n'est pas asses compliqué, on peut utiliser dselect qui est obsolète et non recommandé sur les distributions modernes. Il y a aussi dpkg-deb et dpkg-split. Bref pas facile de s'y retrouver.

Pour les .rpm il existe plusieurs versions dont une qui serait morte. On ne peut pas dire que la commande rpm soit très explicite :

rpm -i nom.rpm pour installer. Attention, -i peut aussi désigner le texte décrivant le paquet selon le contexte (-ivh ou -qilp).
rmp -U nom.rpm (pourquoi une majuscule ?)
rpm -e nom pour désinstaller (e comme …)

De toute façon sous fedora il vaut mieux utiliser yum qui est à peu près aussi simple que slackpkg.

Les mises à jour.

Autre tour de force de Slackware : proposer des mises à jour jusqu'à la version 8.1 (sortie le 19 juin 2002) pour certains programmes comme bind. Comme Pat ne modifie pas les logiciels tant que l'upstream (je n'ai pas trouvé de terme plus adéquat) fait des mises à jour il les applique à la Slack.
De plus, en suivant les instructions CHANGES_AND_HINTS.TXT et UPGRADE.TXT il est possible de suivre les changements de version sans casser son système.

Bref, joyeux anniversaire Slackware et bonne continuation!

Have fun!

  • # Troll gratuit

    Posté par  (site web personnel) . Évalué à 10.

    J'ai pertinenté, mais quand même ce troll gratuit est bien dommage.

    Et puis de tout façon tout le monde sait que le meilleur gestionnaire de paquet est portage.

    Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

  • # Upstream

    Posté par  (site web personnel) . Évalué à 2.

    « Upstream » se dit « amont », en français. Selon le contexte, ça donnes des expression comme « les développeurs amont » ou « la version amont ».

    • [^] # Re: Upstream

      Posté par  (site web personnel) . Évalué à 8.

      À qui?

    • [^] # Re: Upstream

      Posté par  . Évalué à 6.

      sauf que amont est un nom, pas un adjectif. Pour l'utiliser comme tu le fais, il faudrait plutôt dire « les développeurs en amont ».

      La seule fois où ça peut se dire ainsi, c'est pour les orgues amont ;)

      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

  • # DEB

    Posté par  (site web personnel) . Évalué à 10.

    Sous Debian il y a d'après la FAQ dpkg < apt < aptitude < synaptic et tasksel, mais la FAQ n'explique pas comment utiliser ce dernier.

    tasksel est fait pour l'installateur. C'est une interface de sélection de paquets, concurrente en cela à aptitude, synaptic et dselect qui est caduque.

    Il y a aussi dpkg-deb et dpkg-split.

    Rien à voir, dpkg-deb c'est pour inspecter, manipuler des paquets sans les installer. Quant à dpkg-split, je n'en avais jamais entendu parler, mais il a encore moins à voir, il sert à couper des paquets en plusieurs morceaux pour les transférer sur des disquettes trop petites pour les accueillir en entier.

    • [^] # Re: DEB

      Posté par  . Évalué à 10.

      Déjà considérer une FAQ comme une documentation c'est fort, mais en plus considérer le fait d'avoir plusieurs commandes comme une complexité ça montre juste qu'on est vendredi.

      Au passage pour les usages sus-cités Debian n'a que 2 commandes (dpkg et apt-get) là où slack en a 4 (installpkg, removepkg, upgradepkg et slackpkg). Du coup pour avoir la doc dans Debian c'est réunis dans deux pages man là où il faut en lire 4 pour slack.

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

      • [^] # Re: DEB

        Posté par  (site web personnel) . Évalué à 3.

        Au passage pour les usages sus-cités Debian n'a que 2 commandes (dpkg et apt-get) là où slack en a 4

        Sous Slackware, tu peux aussi simplement lancer pkgtool qui te permet de tout faire avec une interface ncurses :

        pkgtool 13.37

        Alors oui, c'est basique et ça ne gère pas les dépendances, mais c'est la philosophie de la distribution.

      • [^] # Re: DEB

        Posté par  (Mastodon) . Évalué à 8.

        Debian n'a que 2 commandes (dpkg et apt-get)

        La légende selon quoi on pourrait tout faire avec aptitude serait-elle une légende ?

        • [^] # Re: DEB

          Posté par  . Évalué à 9.

          La question est toujours débattue un peu partout en fait.

          Alors de mémoire, aptitude était recommandé pour la gestion quotidienne des paquets depuis Sarge je crois, car il disposait d'une meilleure gestion des dépendances.
          À l'époque, apt par exemple ne savait pas désinstaller les packages installés en tant que dépendances si les paquets qui en dépendaient avaient tous été supprimés.
          Aptitude lui savait gérer cela.
          D'ailleurs, il était aussi déconseillé d'utiliser les 2 en parallèle, car cela pouvait entrainer de problèmes dans la gestion des dépendances.

          Maintenant, ce n'est plus le cas, mais aptitude reste plus pratique sur plein de points notamment la possibilité de gérer les paquets plus simplement depuis la même commande, et permet aussi une gestion plus fine des dépendances.

          Pour citer la FAQ Debian à ce sujet :
          http://www.debian.org/doc/FAQ/ch-pkgtools.en.html

          Note that apt-get now installs recommended packages as default and is the preferred program for package management from console to perform system installation and major system upgrades for its robustness.

          et

          Note that aptitude is the preferred program for daily package management from console.

          Donc en résumé, les recommandations officielles de Debian sont :
          - aptitude pour la gestion quotidienne des packages
          - apt-get pour les installations et mises à jour majeures

          *Sano*

          • [^] # Re: DEB

            Posté par  (Mastodon) . Évalué à 2.

            Donc en résumé, les recommandations officielles de Debian sont :
            - aptitude pour la gestion quotidienne des packages
            - apt-get pour les installations et mises à jour majeures

            La frontière entre les deux me semble assez floue, et dans quel camp faut-il classer synaptic ? C'est pas très clair, tout ça...

            • [^] # Re: DEB

              Posté par  (site web personnel) . Évalué à 8.

              Ils sont tous interchangeables, comme peuvent l'être Iceweasel, Chromium et Epiphany.

              • [^] # Re: DEB

                Posté par  . Évalué à -6.

                donc il y en a un de trop. à minima

            • [^] # Re: DEB

              Posté par  . Évalué à 3.

              Synaptic, c'est à utiliser quand tu as besoin d'une interface graphique.

              « 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

          • [^] # aptitude vs apt-get, une différence

            Posté par  . Évalué à 2.

            Donc en résumé, les recommandations officielles de Debian sont :
            - aptitude pour la gestion quotidienne des packages
            - apt-get pour les installations et mises à jour majeures

            Alors, pour avoir vu le cas sur une Ubuntu : si ton système n’est pas vraiment à jour et que tu as besoin d’ajouter un paquet, aptitude voudra tout te mettre à jour, tandis qu’apt-get, non.
            Si tu as une bonne connexion, je te conseillerais donc aptitude (comme ça, pas de risque d’avoir des problèmes avec des dépendances un peu trop vieilles), mais si tu es sur une connexion pourrie et que tu as besoin de ton logiciel rapidement, surtout pas !

            « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

      • [^] # Re: DEB

        Posté par  . Évalué à 1.

        Si j'ai regardé la FAQ c'est parce qu'il y a plusieurs commandes qui font la même chose (gérer les paquets) et que je ne savais pas laquelle il fallait prendre. De plus, ça permettait de voir l'évolution du gestionnaire sur 18 ans. Là où Slackware utilise toujours les pkgtools, Debian a essayé plusieurs systèmes sans que ce ne soit forcement très clair (cf. les différentes discussions sur ce site). Pour moi, ce n'est ni KISS ni dans la philosophie unix (un outil pour une tâche).

        Slackware a aussi évolué. On est passé du .tgz au .txz avec compression lzma pour de meilleure performance, on utilise slackpkg pour la mise à jour de la distribution à travers le réseau et sbopkg pour installer les programmes non-officiels à partir des slackbuilds. Mais on peut utiliser installpkg et slackpkg ensemble sans casser le système. Les nouveaux outils ne remettent pas en cause les anciens et simplifient juste certaines tâches administratives.

        • [^] # Debian vs KISS

          Posté par  . Évalué à -3.

          Pour moi, ce n'est ni KISS ni dans la philosophie unix (un outil pour une tâche).

          Debian piétine allègrement et sans raison valable le principe KISS à plusieurs endroits, à commencer par l’organisation même des dépôts.
          Va-t-en maintenir sur disque amovible un miroir de la version courante pour mettre à jour une machine qui n’a pas d’accès à Internet rapide...

          Debian, c’est une distribution faite par des coupeurs de cheveux en quatre pour des coupeurs de cheveux en quatre.

          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

          • [^] # Re: Debian vs KISS

            Posté par  . Évalué à 6.

            Va-t-en maintenir sur disque amovible un miroir de la version courante

            Je fais ça sur un disque non amovible sans soucis. Qu'est ce qui est susceptible de poser problème ?
             
             

            Debian, c’est une distribution faite par des coupeurs de cheveux en quatre pour des coupeurs de cheveux en quatre.

            Depuis plusieurs années je n'ai eu que 4 ou 5 soucis avec la gestion des paquets. A chaque fois sur des machines pas à jour (comme celle que j'utilise actuellement qui est une Sid de 2008 bricolée à mort). Plus quelques gags genre installer des polices de caractères pour un utilitaire en ligne de commande. Je doute qu'aucune distribution ne soit à l'abris.
            Ton commentaire s'applique peut-être à autre chose. Mais Debian est, malgré/grâce à son coupage de cheveux, une distribution très stable. Elle fait partie des distributions super pratiques pour des serveurs sans avoir à y passer des heures. Et elle fonctionne très bien pour les postes de travail.

            Les BSD sont aussi des distributions de coupeurs de cheveux. Avec les avantages et inconvénients que l'on connaît. Sachant que les avantages sont disponibles pour tous (ssh, amélioration du code d'un peu tout le monde, etc) et les inconvénients disponibles uniquement pour ceux qui ont un BSD. Pareil pour Debian. Pareil pour Red Hat. Etc.

            • [^] # Re: Debian vs KISS

              Posté par  . Évalué à -5.

              Va-t-en maintenir sur disque amovible un miroir de la version courante

              Je fais ça sur un disque non amovible sans soucis. Qu'est ce qui est susceptible de poser problème ?

              Pour une distribution « normale », il suffit de copier le répertoire de la version courante.
              Sous Debian, les répertoires sont mélangés entre les versions et séparés par lettre, c’est inutilisable directement !
              Alors il y a probablement une commande pour faire ça, mais c’est une complication inutile.

              Les BSD sont aussi des distributions de coupeurs de cheveux.

              Les développeurs des *BSD sont des pinailleurs, mais il ne poursuivent pas le même but du tout : ils cherchent la qualité et la simplicité.

              Sous Debian, une demi-douzaine de commandes pour gérer les paquets, ça ne ressemble plus à rien.

              Elle fait partie des distributions super pratiques pour des serveurs sans avoir à y passer des heures.

              À condition de n’avoir aucun besoin particulier.
              J’avais regardé à un moment pour un serveur web : Apache n’était pas compilé avec le support des bibliothèques dont j’avais besoin. Sur les autres distributions, si.

              Sur une Debian stable, j’ai voulu installer un paquet d’un truc graphique de la testing, parce que j’en voulais une version récente.
              apt-get a voulu une version plus récente de la Xlib, c’était raisonnable, j’essaye donc de la mettre à jour aussi.
              Résultat : il me dit OK pas de problème, je vais désinstaller la majorité des applications graphiques...
              À moins d’une très grande différence de versions, la Xlib a pour autant que je sache toujours conservé la compatibilité ascendante ; d’ailleurs, j’ai souvent utilisé sans problème des applications compilées par rapport à des versions de la Xlib plus anciennes que celle que j’avais sur mon système. Pour le mélange de paquets de différentes versions, je l’ai aussi fait sur d’autres distributions, et avec succès (même une fois une mise-à-jour de rpm et de la glibc pour des versions majeures plus récentes, autre chose que Xlib !).
              Mais les empaqueteurs psychorigides de Debian ont décidé de mettre une dépendance stricte sur la version de la Xlib et pas juste une version minimale comme sur n’importe quelle autre distrib.

              En fait, ça, c’était sur le conseil d’un sysadmin debianiste : « non, tu devrais quand même prendre la stable, tu configures les dépôts pour pouvoir prendre des paquets de la testing en le spécifiant » (une demi-journée ! mais il est vrai que je ne pouvais pas envisager de prendre les paquets à la main comme sur une distribution avec des dépôts normaux) « et tu pourras ajouter les quelques paquets plus récents dont tu as besoin, ça gère les dépendances, ça marche super-bien ». Bah voyons !
              Bon, c’était un essai, j’ai encore une fois jeté la Debian. En fait, je n’en ai jamais mis en production.

              Quand j’ai dû intervenir sur des Ubuntu (pas installées par moi), je suis tombé sur quelques autres trucs tordus (et pénibles) certainement hérités de Debian, mais quand même pas aussi calamiteux que le système de paquets.

              Je crois que je préférerais encore devoir administrer une Slackware (pas de gestion des dépendances) qu’une Debian.

              Suggestion : jetez tout le système de paquets, passez à pacman.

              « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

              • [^] # Re: Debian vs KISS

                Posté par  (site web personnel) . Évalué à 2.

                Sous Debian, une demi-douzaine de commandes pour gérer les paquets, ça ne ressemble plus à rien.

                Si tu n'aimes pas avoir le choix, il y'a Mac App Store de Apple.

                À condition de n’avoir aucun besoin particulier.
                J’avais regardé à un moment pour un serveur web : Apache n’était pas compilé avec le support des bibliothèques dont j’avais besoin. Sur les autres distributions, si.

                Et oui, à un moment des choix sont fais et c'est ainsi partout. Si je veux ZFS, je prend pas Linux. Après tu as plusieurs méthodes pour arriver au résultat voulu, prendre une autre distribution est un choix, compiler Apache pour ton besoin est un autre.

                Sur une Debian stable, j’ai voulu installer un paquet d’un truc graphique de la testing, parce que j’en voulais une version récente.

                C'est l'essence même de de Debian. Tu prends la stable et tu sais que tu n'as pas de changement en terme de comportement durant toute la durée de vie. Si tu veux faire du mélange, tu peux, mais c'est de l'utilisation avancée et tu dois t'attendre à prendre des risques et casser ton système.

                D'ailleurs la stable, la testing et la unstable sont considérées comme trois distributions majeures par le projet Debian. Mélanger deux, revient à mélanger Gentoo et Redhat, par exemple.

                "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                • [^] # Re: Debian vs KISS

                  Posté par  . Évalué à 2.

                  Si tu n'aimes pas avoir le choix, il y'a Mac App Store de Apple.

                  De suite les gros mots. Il y a une différence entre avoir le choix et compliquer inutilement une opération qui devrait être simple.

                  compiler Apache pour ton besoin est un autre.

                  N'ayant jamais fait ça sous une distribution gérant les dépendances, ça se passe comment lors d'une mise à jour ? J'imagine que tu interdits la mise à jour du paquet modifié, mais qu'est-ce qui se passe pour les paquets qui dépendent de celui-ci ?

                  • [^] # Re: Debian vs KISS

                    Posté par  (site web personnel) . Évalué à 2.

                    N'ayant jamais fait ça sous une distribution gérant les dépendances, ça se passe comment lors d'une mise à jour ? J'imagine que tu interdits la mise à jour du paquet modifié, mais qu'est-ce qui se passe pour les paquets qui dépendent de celui-ci ?

                    aptitude install equivs
                    man equivs-control
                    man equivs-build

                    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                    • [^] # Re: Debian vs KISS

                      Posté par  . Évalué à 1.

                      Ok, alors si j'ai bien compris, voilà ce qu'il faut faire :
                      - on part d'un paquet A.deb que l'on recompile (pour ajouter une dépendance au ./configure par exemple).
                      - on crée un paquet A-moi.deb
                      - on fait la mise à jour de A.deb avec A-moi.deb
                      - on crée un paquet vide appelé A.deb comme ça, pour B.deb qui dépend de A.deb A est toujours là.

                      Maintenant, ma question, si je dois mettre à jour qu'est-ce qui se passe ? A.deb (le faux) devient A+1.deb (un vrai paquet) ? A-moi.deb reste ? Disparait ? Ou alors il faut nettoyer à la main le système ?

                      • [^] # Re: Debian vs KISS

                        Posté par  (site web personnel) . Évalué à 4.

                        Si tu modifies un paquet c'est plus simple. Tu utilises les outils Debian pour obtenir le paquet source, tu modifies le paquet source (patch, modification des options de compilation), tu ajoutes ton numéro de version (genre +0.local.1 au numéro actuel) et tu utilises les outils Debian pour reconstruire le paquet et l'installer proprement. Ton paquet ne sera pas mis à jour automatiquement, c'est à toi de le gérer. Par contre si tu ton paquet est 1.2-0+0.local.1 et que Debian fourni 1.3-0, aptitude va vouloir le mettre à jour (mais ce changement ne devrait pas se produire durant la durée de vie d'une stable).

                        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                        • [^] # Re: Debian vs KISS

                          Posté par  . Évalué à 1.

                          Tu utilises les outils Debian pour obtenir le paquet source, tu modifies le paquet source (patch, modification des options de compilation), tu ajoutes ton numéro de version (genre +0.local.1 au numéro actuel) et tu utilises les outils Debian pour reconstruire le paquet et l'installer proprement.

                          Enfin une solution humaine ! C’est ce que je fais avec d’autres distributions quand j’ai besoin de modifier un paquet (sauf que je me contente de lftp pour charger le paquet source).
                          En fait, quand j’ai testé la Debian, j’ai voulu tenter de faire les choses façon Debian et j’ai donc demandé conseil au debianiste du coin. C’était sûrement là l’erreur.

                          Par contre si tu ton paquet est 1.2-0+0.local.1 et que Debian fourni 1.3-0, aptitude va vouloir le mettre à jour

                          Pour éviter ce risque, je trafique le numéro de version en y ajoutant un nombre assez important et rond ; ça ferait par exemple 1.1002-0. Comme ça, pas de mise à jour intempestive, mais on voit quand même que ça a été trafiqué et on peut deviner la version d’origine.

                          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                          • [^] # Re: Debian vs KISS

                            Posté par  (site web personnel) . Évalué à 4.

                            En fait, quand j’ai testé la Debian, j’ai voulu tenter de faire les choses façon Debian et j’ai donc demandé conseil au debianiste du coin. C’était sûrement là l’erreur.

                            C'est la façon Debian de faire. Il y'a un excellent (fr) livre écrit par dev Debian : "Debian, Administration et configuration avancée" chez Eyrolles (ISBN: 2-212-11904-6) où tu trouveras tout ça et même plus.

                            Pour éviter ce risque, je trafique le numéro de version en y ajoutant un nombre assez important et rond ; ça ferait par exemple 1.1002-0. Comme ça, pas de mise à jour intempestive, mais on voit quand même que ça a été trafiqué et on peut deviner la version d’origine.

                            Ça c'est déjà une moins bonne idée et ça n'apporte rien sinon des soucis. Parce que dans la stable le numéro ne va pas changer (normalement) et si tu es sur testing ou unstable, tu peux étiqueter la version de ton paquet dans /etc/apt/preferences :

                            Package: monpaquet
                            Pin: version 1.2-0+0.local.1
                            Pin-Priority: 2000
                            

                            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                            • [^] # Re: Debian vs KISS

                              Posté par  (site web personnel) . Évalué à 3.

                              Une autre solution pour empêcher la mise intempestive du paquet :

                              aptitude hold tonpaquet
                              

                              Cette option sert justement à marquer un parquet pour indiquer à apt et aptitude de ne pas le mettre à jour automatiquement.

                            • [^] # Re: Debian vs KISS

                              Posté par  . Évalué à 1.

                              Ça c'est déjà une moins bonne idée et ça n'apporte rien sinon des soucis.

                              De quel genre, à part une éventuelle dépendance d’un autre paquet à la toute dernière version ?

                              Ce que ça apporte par rapport à une exclusion du paquet (il n’y a pas que sous Debian que c’est possible), c’est qu’en cas de mise à jour du paquet d’origine, je refais le mien, je le mets dans le dépôt local et les machines le prennent à leur mise à jour suivante. Pas besoin de commande spécifique, simple (KISS, quoi).

                              Après, je maintiens aussi une liste d’exclusion centralisée pour des paquets qui causeraient problème (quelquefois un paquet du dépôt contrib cause un conflit avec un autre, alors que son ancienne version passait).

                              « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                              • [^] # Re: Debian vs KISS

                                Posté par  (site web personnel) . Évalué à 3.

                                Si quelqu'un reprend derrière toi, il risque de pas comprendre et il va être énervé (et s'il est plus costaud que toi, il risque de te démonter la tête à grand coups de latte). En plus je trouve ça pas propre.

                                "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                • [^] # Re: Debian vs KISS

                                  Posté par  . Évalué à 2.

                                  Si quelqu'un reprend derrière toi, il risque de pas comprendre

                                  Si quelqu’un reprend derrière moi, il trouvera ce paquet dans le dépôt local avec les quelques paquets complètement spécifiques (c’est un dépôt séparé des copies locales des dépôts officiel), à maintenir aussi.

                                  et il va être énervé et s'il est plus costaud que toi, il risque de te démonter la tête à grand coups de latte).

                                  Si quelqu’un reprend derrière moi, soit je serai là sur une autre tâche et je l’aiderai à se repérer... soit je serai loin ! ;-)
                                  Bon, en fait, j’ai déjà un collègue au courant de l’organisation générale du truc.

                                  En plus je trouve ça pas propre.

                                  Oui, mais tu es un debianiste, c’est ta tendance naturelle à pinailler. ;-)

                                  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                              • [^] # Re: Debian vs KISS

                                Posté par  . Évalué à 2.

                                La modification du préférence te permet d'autoriser les mises à jour venant de ton dépôt et pas des dépôts officiels.

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

                          • [^] # Re: Debian vs KISS

                            Posté par  . Évalué à 2.

                            Enfin une solution humaine ! C’est ce que je fais avec d’autres distributions quand j’ai besoin de modifier un paquet (sauf que je me contente de lftp pour charger le paquet source).

                            Avec lftp il faut le faire pointer vers un dépôt là où apt-get source zsh va te télécharger le paquet depuis tes dépôts avec les sources mainstream et toutes les modifications faites par Debian séparées.

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

                • [^] # Re: Debian vs KISS

                  Posté par  . Évalué à 0.

                  Si tu n'aimes pas avoir le choix, il y'a Mac App Store de Apple.

                  J’aime avoir le choix. Par exemple, le choix d’un paquet Apache compilé avec toutes les options, le choix de pouvoir essayer un paquet plus récent...
                  Là, ce n’est pas le choix des commandes, c’est le choix des effets de bord (encore faut-il en être conscient !). C’est de la complexité, pas un choix utile.
                  Pour la gestion des paquets, j’aime mieux avoir une seule commande ou un ensemble de commandes cohérent pour les opérations de base (genre pacman) ; il est toujours temps de proposer un choix sur les frontends.

                  Et oui, à un moment des choix sont fais et c'est ainsi partout.

                  Oui, mais pas aux bons endroits : dommage que ce ne soit pas sur la gestion des paquets...

                  Après tu as plusieurs méthodes pour arriver au résultat voulu, prendre une autre distribution est un choix, compiler Apache pour ton besoin est un autre.

                  Encore un mauvais conseil d’un debianiste : faire le choix de compiler, ce n’est pas anodin, ça implique de recompiler à chaque mise à jour de sécurité.
                  Ça m’est arrivé pour des besoins très spécifiques, mais dans les cas courants, c’est à éviter. Ou alors, il faut prendre une Gentoo (on compile, mais les mises-à-jour sont gérées).

                  Tu prends la stable et tu sais que tu n'as pas de changement en terme de comportement durant toute la durée de vie.

                  Même les bugs très gênants restent (parce qu’autrement, ce serait dommage) : par exemple, une version d’IceWM avec un bug très gênant sur le placement des fenêtres (la seule à l’avoir parmi des tas de versions plus anciennes ou plus récentes que j’ai utilisées) est bien restée.

                  Si tu veux faire du mélange, tu peux, mais c'est de l'utilisation avancée et tu dois t'attendre à prendre des risques et casser ton système.

                  Il y en a qui le conseillent (vu le résultat, c’est idiot).
                  Il y a des tutoriaux pour ça (pareil).
                  Pour le truc que j’ai essayé, ça ne casserait pas le système, et au pire, j’aurais pris le risque.
                  Mais les empaqueteurs empêchent de le faire ; c’est la seule distribution (au moins dans celles que j’ai utilisées et sans compter les dérivées de Debian) où les paquets contiennent des dépendances strictes là où des versions minimales conviendraient.
                  Sur les autres distributions, on peut au moins essayer ; là encore, pas le choix justement.
                  Enfin au moins, c’est bien assorti avec Gnome...

                  Mélanger deux, revient à mélanger Gentoo et Redhat, par exemple.

                  Mauvaise foi, l’architecture de la distribution reste la même. Ça reviendrait à mélanger une CentOS 5 avec une 6 (je prends l’exemple d’une distribution qui ne sort pas plus fréquemment). Et si un debianiste me demandait conseil à ce propos, je lui conseillerais d’éviter si possible et en tout cas d’essayer de recompiler les paquets pour limiter les dépendances (sauf peut-être au crétin qui m’avait donné le mauvais conseil pour la Debian).

                  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                  • [^] # Re: Debian vs KISS

                    Posté par  (site web personnel) . Évalué à 5.

                    Pour la gestion des paquets, j’aime mieux avoir une seule commande ou un ensemble de commandes cohérent pour les opérations de base (genre pacman) ; il est toujours temps de proposer un choix sur les frontends.

                    Ce qui est le cas. Le gestionnaire de paquet est dpkg, les autres ne sont que des interfaces de haut-niveau. En passant par dpkg, tu peux télécharger un .deb et l'installer en ignorant les dépendances. Il suffit de lire la man page de dpkg.

                    dpkg = pacman

                    Après, avec aptitude ou apt, tu peux faire des mélanges, mais ça demande un peu plus de connaissances que trois options sur une ligne de commande.

                    Encore un mauvais conseil d’un debianiste : faire le choix de compiler, ce n’est pas anodin, ça implique de recompiler à chaque mise à jour de sécurité.
                    Ça m’est arrivé pour des besoins très spécifiques, mais dans les cas courants, c’est à éviter. Ou alors, il faut prendre une Gentoo (on compile, mais les mises-à-jour sont gérées).

                    Je ne pense pas que tu parlais des cas courant pour ta librairie particulière qu'uniquement Debian ne possédait pas. Après pour l'histoire de Xlib je suppose que ce n'était pas sur un serveur en production.

                    Mais les empaqueteurs empêchent de le faire ; c’est la seule distribution (au moins dans celles que j’ai utilisées et sans compter les dérivées de Debian) où les paquets contiennent des dépendances strictes là où des versions minimales conviendraient.
                    Sur les autres distributions, on peut au moins essayer ; là encore, pas le choix justement.

                    dpkg --force-all -i paquet.deb

                    Mauvaise foi, l’architecture de la distribution reste la même.

                    Pas vraiment. Le format de paquet est le même, l'architecture pas forcément. Généralement ça l'est.

                    Je crois qu'il s'agit plus d'une méconnaissance de Debian que de choix imposer par Debian. Debian, et c'est ce que j'aime, ne se met pas en travers du chemin si tu essaies de faire des subtilités non prévues et fournis même des outils pour aider (si tu veux les utiliser), par exemple si tu veux compiler ton propre paquet qui va remplacer un paquet nécessaire à Debian, tu peux utiliser equivs pour ça.

                    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                    • [^] # Re: Debian vs KISS

                      Posté par  . Évalué à 1.

                      En passant par dpkg, tu peux télécharger un .deb et l'installer en ignorant les dépendances. Il suffit de lire la man page de dpkg.

                      Je sais lire les man et j’ai déjà utilisé dpkg.
                      Le problème est dans « télécharger ». Quand il faut trouver un paquet dans le foutoir d’un dépôt Debian, c’est un peu plus compliqué que sur une autre distribution. Quand il y a aussi un certain nombre de dépendances qu’il faut trouver dans la bonne version, c’est juste la merde (à moins qu’ils ne se soient enfin décidés à ranger les paquets par version de la distribution ; si c’est le cas, je serai content de l’apprendre).

                      dpkg = pacman

                      Non, pacman fait aussi le boulot d’apt-get voire d’autres commandes (voir ici).

                      Après, avec aptitude ou apt, tu peux faire des mélanges, mais ça demande un peu plus de connaissances que trois options sur une ligne de commande.

                      Je sais bien, c’est pour ça que ça m’a pris pas mal de temps pour mettre ça à peu près au point. Tout ça pour me faire avoir par les dépendances strictes sur les paquets...

                      Après pour l'histoire de Xlib je suppose que ce n'était pas sur un serveur en production.

                      Non, mais après tout ça n’aurait pas été un gros soucis : les outils d’administration graphiques peuvent éventuellement être impactés par un tel changement, mais pas les services.

                      Au delà, en maintenant un serveur dont la distribution n’avait plus de mises à jour, j’avais fini avec un noyau vanilla beaucoup plus récent compilé à la main, des paquets binaires des deux versions suivantes (dont la glibc) et des paquets de celle d’après recompilés. Finalement, le système était plus stable qu’au départ (pas très dur : le noyau d’origine était un des premiers 2.4, avec une version de NFS franchement boguée) et même plus stable que la distribution que j’ai installée après (jusqu’à ce que j’aie aussi repéré et pris en compte les bugs des logiciels qui la composent).

                      Debian, et c'est ce que j'aime, ne se met pas en travers du chemin si tu essaies de faire des subtilités non prévues et fournis même des outils pour aider (si tu veux les utiliser), par exemple si tu veux compiler ton propre paquet qui va remplacer un paquet nécessaire à Debian, tu peux utiliser equivs pour ça.

                      Debian fait des trucs complexes et éventuellement d’autres trucs complexes (qu’il faut trouver) pour permettre de contourner les premiers si on a des besoins particuliers. Ce n’est pas ce que j’appelle ne pas se mettre en travers du chemin.
                      La distribution qui ne se met vraiment pas en travers du chemin, c’est Slackware : elle fait juste le minimum et après, tu te démerdes « à la main », comme sur n’importe quel Unix.

                      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                      • [^] # Re: Debian vs KISS

                        Posté par  (site web personnel) . Évalué à 4.

                        Je sais lire les man et j’ai déjà utilisé dpkg.
                        Le problème est dans « télécharger ». Quand il faut trouver un paquet dans le foutoir d’un dépôt Debian, c’est un peu plus compliqué que sur une autre distribution. Quand il y a aussi un certain nombre de dépendances qu’il faut trouver dans la bonne version, c’est juste la merde (à moins qu’ils ne se soient enfin décidés à ranger les paquets par version de la distribution ; si c’est le cas, je serai content de l’apprendre).

                        aptitude download paquet

                        Non, pacman fait aussi le boulot d’apt-get voire d’autres commandes (voir ici).

                        C'est un choix. Là c'est un outil qui s'occupe d'installer/supprimer les paquets et un outil qui s'occupe d'obtenir les paquets.

                        La distribution qui ne se met vraiment pas en travers du chemin, c’est Slackware : elle fait juste le minimum et après, tu te démerdes « à la main », comme sur n’importe quel Unix.

                        Debian ne fait rien à moins que tu lui demande de faire quelque chose. Tu peux entièrement administrer ton système à coups d'aptitude download et dpkg -i, c'est à toi de décider ce que tu veux. Par contre c'est très puissant, mais ça reste très progressif. Tu peux partir de débutant et finir maître, en utilisant Debian, et avoir remplacé toutes les briques du système pour faire tourner GNU/Hurd (ah, on me dit que c'est déjà fait).

                        Perso j'utilise/ai utilisé plein de distribution. Pour toi, tu fais ce que tu veux ça me change pas le prix de la bière. Par contre il est bien de savoir ce qu'il est possible de faire avec une distribution. La première fois que j'ai utilisé Debian, j'ai jeté après une semaine en disant comme toi ...

                        Par contre je pensais testé Slackware pour me faire un Dom0 Linux 3.0 en ayant la distribution m'installant le stricte nécessaire et "disparaître" ... un genre LFS mais l'installation automatique (ALFS m'attire pas vraiment), je sais pas si ça fonctionnerait bien ça ?

                        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                        • [^] # Re: Debian vs KISS

                          Posté par  . Évalué à 1.

                          Par contre je pensais testé Slackware pour me faire un Dom0 Linux 3.0 en ayant la distribution m'installant le stricte nécessaire et "disparaître" ... un genre LFS mais l'installation automatique (ALFS m'attire pas vraiment), je sais pas si ça fonctionnerait bien ça ?

                          Slackware fonctionne aujourd'hui comme une base sur laquelle on peut construire ce que l'on veut.

                          Voilà de la doc pour réaliser le dom0 :
                          - ici le slackbuild (script pour compiler et créer des paquets pour slackware) de xen.
                          - pour le dom0

                          Pour utiliser Linux 3.0 il semblerait qu'il y ait quelques problèmes avec uname mais je ne sais pas si c'est spécifique à Slackware

                          Bonne chance

                          • [^] # Re: Debian vs KISS

                            Posté par  (site web personnel) . Évalué à 2.

                            Pour utiliser Linux 3.0 il semblerait qu'il y ait quelques problèmes avec uname mais je ne sais pas si c'est spécifique à Slackware

                            Je penses pas mais Debian testing a commencé à intégrer Linux 3.0, je pourrais aller piocher là-dedans.

                            Bonne chance

                            Merci.

                            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                        • [^] # Re: Debian vs KISS

                          Posté par  . Évalué à 1.

                          aptitude download paquet

                          Merci, j’avais loupé cette option (je n’en ai jamais eu besoin sur une autre distribution et je n’y ai tout simplement pas pensé). Ça pourra me servir (au moins quand j’interviens sur des Ubuntu).

                          Après, j’ai déjà été confronté à un cas où ça n’aurait pas résolu pas le problème : un dépôt tiers dont les commandes apt* avaient estimé que le fichier descriptif était défectueux. C’était sûrement vrai, mais du coup, au revoir apt*, retour au téléchargement à la main en essayant de deviner quelle version pouvait bien correspondre à la distribution...
                          Je reste donc convaincu que séparer les paquets par version de la distribution est un bon principe (simple, pratique).

                          Pour les dépendances strictes plutôt qu’à une version minimale, ça ne résoud pas non plus. Il faut modifier et recompiler le paquet source.

                          Non, pacman fait aussi le boulot d’apt-get voire d’autres commandes (voir ici).

                          C'est un choix.

                          Un choix qui a des avantages : à ce que j’ai vu, aussi bien dans le monde Debian que dans le monde rpm, les commandes de haut niveau court-circuitent la commande de base (dpkg ou rpm) pour plus d’efficacité et éventuellement maintiennent une base supplémentaire.
                          Du coup, utiliser une commande de haut niveau ou de base n’assure pas d’un résultat parfaitement identique. Avec une seule commande, aucun soucis.

                          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                          • [^] # Re: Debian vs KISS

                            Posté par  (site web personnel) . Évalué à 4.

                            Un choix qui a des avantages : à ce que j’ai vu, aussi bien dans le monde Debian que dans le monde rpm, les commandes de haut niveau court-circuitent la commande de base (dpkg ou rpm) pour plus d’efficacité et éventuellement maintiennent une base supplémentaire.

                            Non, apt et aptitude utilisent dpkg via libapt-pkg

                            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                      • [^] # Re: Debian vs KISS

                        Posté par  . Évalué à 3.

                        Le problème est dans « télécharger ». Quand il faut trouver un paquet dans le foutoir d’un dépôt Debian, c’est un peu plus compliqué que sur une autre distribution. Quand il y a aussi un certain nombre de dépendances qu’il faut trouver dans la bonne version, c’est juste la merde (à moins qu’ils ne se soient enfin décidés à ranger les paquets par version de la distribution ; si c’est le cas, je serai content de l’apprendre).
                        

                        Pour ça il y a le site http://packages.debian.org/

  • # la commande MAN

    Posté par  . Évalué à 2.

    Sous Debian il y a d'après la FAQ dpkg < apt < aptitude < synaptic et tasksel, mais la FAQ n'explique pas comment utiliser ce dernier.

    http://man.cx/aptitude%288%29
    idem pour les autres outils suscités.
    La commande man est un outil merveilleux.

    Pour chaque personne qui me plussoie, je frappe un fan de Justin Bieber.

    • [^] # Re: la commande MAN

      Posté par  (site web personnel) . Évalué à 10.

      dans le cadre des lois de parité, une commande woman a été demandée, à des fins d'équité :-)

      • [^] # Re: la commande MAN

        Posté par  . Évalué à 10.

        à des fins d'équité

        C'est quoi ces histoires de cheval ?

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

    • [^] # Re: la commande MAN

      Posté par  (site web personnel) . Évalué à 8.

      D'autant que fournir un manuel pour chaque commande est obligatoire, selon la charte Debian.

      • [^] # Re: la commande MAN

        Posté par  . Évalué à -6.

        très peu sont de qualité

        • [^] # Re: la commande MAN

          Posté par  (site web personnel) . Évalué à 2.

          Dans ce cas, le mieux à faire est de signaler ces manques en faisant des rapports de bogue, niveau de gravité serious. Ces rapports devraient être traités assez rapidement par les mainteneurs correspondants étant donnés qu'ils sont bloquants pour l'admission ou le maintien d'un paquet dans Debian. Autrement dit, avec un bug sérieux, un paquet ne rentrera pas dans la prochaine Debian stable.

          Évidemment, les correctifs sont les bienvenus. Un rapport de bogue, c'est bien, un rapport de bogue avec correctif, c'est mieux.

          • [^] # Re: la commande MAN

            Posté par  . Évalué à 3.

            Mouai, attention à ne pas soulever un nouveau bogue de gravité "serious" pour tout et n'importe quoi.
            Pour une documentation "mal" écrite, il est délicat de dire si le bogue est grave ou pas, c'est très subjectif!
            Le mainteneur aurait vite fait de descendre le bug de quelques niveaux, juste parce que recevoir un bug "serious" expliquant en gros que "ta doc c'est de la merde!", ça ne part pas super bien côté diplomatique...

            • [^] # Re: la commande MAN

              Posté par  (site web personnel) . Évalué à 4.

              Ne pas documenter une commande, c'est une violation de la charte Debian, et ça implique un bogue de gravité serious.

              • [^] # Re: la commande MAN

                Posté par  . Évalué à 4.

                Oui, je sais et je suis bien d'accord.

                Je dis juste qu'il faut faire attention à la différence entre "non documenté" et "mal documenté".

                Dans le deuxième cas, il est pertinent de soulever un bug pour faire comprendre au mainteneur que la doc va de "difficilement utilisable" à "complètement inutilisable mais a le mérite d'exister...".

                Une doc existante mais catastrophique mérite un bug serious. Une doc existante mais pas très claire peut être une raison de soulever un bug moins haut dans la liste des priorités.

                Enfin, une doc pour laquelle le commentaire c'est "pas assez d'exemples", je serais presque tenté d'envoyer le bug en wishlist!

        • [^] # Re: la commande MAN

          Posté par  (site web personnel) . Évalué à 5.

          Très peu, je ne sais pas. Certains sont de mauvaise qualité en effet. Mais par ailleurs, d'autres sont non seulement de bonne qualité, mais ont été adopté par le projet amont. Debian est un moteur de documentation.

  • # Ca veut dire...

    Posté par  . Évalué à 9.

    qu'ont peut enfin mettre des paquets (classes) X dans la distrib ?

  • # c'est aussi la seule distirbution a ne pas integrer gnome

    Posté par  . Évalué à 10.

    ce qui est un choix plutot judicieux vu comme gnome est moche et peu ergonomique

  • # La mère de tous les vices

    Posté par  (site web personnel) . Évalué à 5.

    il existe maintenant pour les feignants slackpkg qui permet d'installer/désinstaller/… à partir d'un dépôt distant

    Les feignants qui font semblant de travailler?

    • [^] # Re: La mère de tous les vices

      Posté par  (site web personnel) . Évalué à 4.

      En effet, ça devrait plutôt être « fainéant », anciennement écrit « faitnéant » : quelqu'un qui ne fait rien. J'ai découvert cette étymologie en lisant le Gargantua en texte original, à l'époque ça s'écrivait ainsi.

      • [^] # Re: La mère de tous les vices

        Posté par  . Évalué à 5.

        Ce n'est pas l'avis de l'Académie française :

        Si, de fait, les formes faignant ou feignant sont aujourd’hui « populaires », elles sont les premières attestées, et c’est fainéant qui a constitué une altération populaire, d’après fait (forme verbale de faire) et néant, de faignant, feignant, participe présent de feindre, au sens ancien de « se dérober (à la tâche), rester inactif ».

        Je regarderai ce qu'en dit mon dictionnaire historique de la langue française ce soir.

        • [^] # Re: La mère de tous les vices

          Posté par  . Évalué à 3.

          Je regarderai ce qu'en dit mon dictionnaire historique de la langue française ce soir.

          Bon, le dictionnaire historique de la langue française dit la même chose : fainénant est une altération de feignant.

Suivre le flux des commentaires

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