Tout arrive, même Slackware 15.0

• # 15.0 disponible pour ARM aussi

  Posté par Yth (Mastodon) le 10 février 2022 à 00:14. Évalué à 10.

  

  Et ce matin la version ARM est officiellement sortie en 15.0 aussi, une semaine après les versions ix86 et x86_64 !

  • Yth, bref, juste le temps d'écrire la dépêche…

• # Slackware n’intègre pas de résolution de dépendances ?

  Posté par Skilgannon le 10 février 2022 à 01:31. Évalué à 5. Dernière modification le 10 février 2022 à 01:32.

  

  Bien le bonjour,

  A part de nom et de ce que montre Adrien dans sa vidéo, je ne connais pas Slackware.

  Je ne comprends pas vraiment la phrase «  le gestionnaire de paquet n’intègre pas de résolution de dépendances ».

  Tel que je le comprend, il faudrait installer et surtout résoudre toutes les dépendances d’un paquet à la main. Par exemple ( et merci cette nouvelle), si je voulais installer « sudo », il faudrait que je cherche sur pkg.org ou autre, non seulement sudo mais aussi que j’installe avant : ibaudit1, libc6, libpam-modules, libpam0g, libselinux1, libselinux1 et zlib1g.

  Or dans la vidéo d’Adrien, c'est bien Libreoffice qui est installé et non pas toute la multitude de librairies dont doit dépendre ce paquet. Ce qui bien que un peu casse pieds est acceptable au contraire de l’exemple avec sudo qui est pour moi rédhibitoire.

  Plus généralement, je suis sous archlinux depuis pas mal de temps et je cherche à tester une autre distribution ou systeme d’exploitation pour changer 1) Pour l’instant j’avais dans ma liste de test possible NixOS ou des BSD comme FreeBSD/GhostBSD mais du coup pourquoi pas Slackware ? Indépendamment bien sûre de la question posé ci-dessus … et du choix plus que douteux des couleurs dans l’installeur !

  1) et aussi, un peu, car le machin-d’init-qui-fait-tout-et-presque-le-café m’agace, pas très Unix dans le sens : « je fais une seule chose, mais je la fais bien » tout cela !

  • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

    Posté par Gil Cot ✔ (site web personnel, Mastodon) le 10 février 2022 à 04:35. Évalué à 10.

    

    Je n'ai pas vu la vidéo, mais comme l'indique Wikipédia

    Slackware inclut son propre gestionnaire de paquets: pkgtool, permettant d'installer, désinstaller, mettre à jour, extraire dans le répertoire courant et créer des paquets. Chacune de ces fonctions est remplie par un script bash utilisable par l'interpréteur de commandes. pkgtool fournit également un environnement en mode texte pour effectuer ces opérations. Les paquets sont de simples archives tar compressées avec gzip, bzip2 ou xz. Depuis le 8 mai 2009, les paquets distribués officiellement sont compressés avec xz.

    Plus précisément

    Slackware's package management system, collectively known as pkgtools, can administer (pkgtool), install (installpkg), upgrade (upgradepkg), and remove (removepkg) packages from local sources. It can also uncompress (explodepkg) and create (makepkg) packages. The official tool to update Slackware over a network or the internet is slackpkg. It was originally developed by Piter Punk as an unofficial way to keep Slackware up-to-date. It was officially included in the main tree in Slackware 12.2 […]
    Slackware packages are tarballs compressed using various methods. Starting with 13.0, most packages are compressed using xz (based on the LZMA compression algorithm), utilizing the .txz filename extension. Prior to 13.0, packages were compressed using gzip (based on the DEFLATE compression algorithm), using the .tgz extension. Support for bzip2 and lzip compression was also added, using the filename extensions .tbz and .tlz respectively, although these are not commonly used.
    Packages contain all the files for that program, as well as additional metadata files used by the package manager. The package tarball contains the full directory structure of the files and is meant to be extracted in the system's root directory during installation. The additional metadata files, located under the special install/ directory within the tarball, usually include a slack-desc file, which is a specifically formatted text file that is read by the package manager to provide users with a description of the packaged software, as well as a doinst.sh file, which is a post-unpacking shell script allowing creation of symbolic links, preserving permissions on startup files, proper handling of new configuration files, and any other aspects of installation that can't be implemented via the package's directory structure. During the development of 15.0, Volkerding introduced support for a douninst.sh uninstall script that can be launched when removing or upgrading a package. This allows package maintainers to run commands when a package is uninstalled.

    Ça c'est pour une petite nouveauté non mentionnée par la dépêche et pour illustrer le fonctionnement global (et donc montrer ce qui a été fait dans la vidéo pour LibreOffice.) La plupart des gestionnaires de paquet fonctionnent d'une façon un peu similaire.
    Maintenant, pour aller plus loin :

    The package manager maintains a local database on the computer, stored in multiple folders. […] Each Slackware installation will contain a packages/ and scripts/ directory in the main database location. The former is where each package installed will have a corresponding install log file (based on the package name, version, arch, and build) that contains the package size, both compressed and uncompressed, the software description, and the full path of all files that were installed. If the package contained an optional doinst.sh post-installation script, the contents of that script will be added to a file in the scripts/ directory matching the filename of the corresponding package in the packages/ directory, allowing the administrator to view the post-installation script at a future point. When a package is removed or upgraded, the old install logs and scripts found under packages/ and scripts/ are moved to removed_packages/ and removed_scripts/, making it possible to review any previous packages and see when they were removed.
    When a package is upgraded, it will install the new package over the old one and then remove any files that no longer exist in the new package. When running upgradepkg, it only confirms that the version numbers are different, thus allowing downgrading the package if desired.

    Donc, comme les autres gestionnaires de paquets, ce qui est fait est tracé mais dans des fichiers textuels et non une base de données binaire. L'organisation est très simple et on peut tout refaire manuellement… (c'était le cas avant le gestionnaire de paquets : on extrayait l'archive et on faisait les opérations demandées par la procédure d'installation qu'on pouvait automatiser en écrivant soi-même le doinst.sh : c'est une distribution qui se veut sans artifice et est idéale pour maîtriser tout ce qui se fait sur le système sans truc auto-magique.) Du coup, oui

    The package management system does not track or manage dependencies; however, when performing the recommended full install, all dependencies of the stock packages are met. For custom installations or 3rd-party packages, Slackware relies on the user to ensure that the system has all the supporting system libraries and programs required by the program. Since no official lists of dependencies for stock packages are provided, if users decide to install a custom installation or install 3rd-party software, they will need to work through any possible missing dependencies themselves. Since the package manager doesn't manage dependencies, it will install any and all packages, whether or not dependencies are met. A user may find out that dependencies are missing only when attempting to use the software.

    Il n'y a vraiment pas de souci pour un paquet officiel (comme pour LibreOffice) : il y a tout ce qu'il faut en général dedans. Quand il y a des bouts de code partagés, l'appli est souvent découpé de sorte à résoudre le souci, comme dans d'autres distributions (on aura par exemple : trucmuche-server, trucmuche-client, trucmuche-tools, trucmuche-common) et la description informe clairement sur les autres dépendances qui ne font pas partie de l'appli (avec sudo, tu auras genre une information qu'il faut : ibaudit1, libpam, libselinux1, et zlib1g …dont la majorité sera déjà installé de base.)
    L'absence de gestion de dépendance n'est vraiment problématique que pour des paquets qui ne sont pas empaquetés pour Slackware, typiquement des trucs récupérés aléatoirement sur la toile. Mais même dans ce cas, si c'est bien documenté on ne doit pas rencontré (trop) de souci. Et sinon (jamais eu besoin pour ma part), si ça peut te rassurer :

    While Slackware itself does not incorporate official tools to resolve dependencies, some unofficial, community-supported software tools do provide this function, similar to the way APT does for Debian-based distributions and yum does for Red Hat-based distributions. They include
    - slapt-get is a command line utility that functions in a similar way to APT. While slapt-get does provide a framework for dependency resolution, it does not provide dependency resolution for packages included within the Slackware distribution. However, several community package sources and Slackware based distributions take advantage of this functionality. Gslapt is a graphical interface to slapt-get.
    - Swaret is a package management tool featuring dependency resolution. It was originally included in Slackware version 9.1 as an optional package, but did not contain dependency resolution at that time. It was removed from the distribution with Slackware 10.0 and turned over to the community. It eventually added dependency resolution and roll-back functionality; however, as of May 2014, there are no active developers.
    - NetBSD's pkgsrc provides support for Slackware, among other Unix-like operating systems. pkgsrc provides dependency resolution for both binary and source packages.

    Comme rien n'est imposé et que c'est fait au plus simple, on peut même fonctionner un peu façon Arch/Gentoo/…

    Due to the possibility of dependency issues, many users choose to compile their own programs using community-provided SlackBuilds. SlackBuilds are shell scripts that will create an installable Slackware package from a provided software tarball. Since SlackBuilds are scripts, they aren't limited to just compiling a program's source; they can also be used to repackage pre-compiled binaries provided by projects or other distributions' repositories into proper Slackware packages. SlackBuilds that compile sources have several advantages over pre-built packages: since they build from the original author's source code, the user does not have to trust a third-party packager; furthermore the local compilation process allows for machine-specific optimization. In comparison to manual compilation and installation of software, SlackBuilds provide cleaner integration to the system by utilizing Slackware's package manager. Some SlackBuilds will come with an additional file with metadata that allows automated tools to download the source, verify the source is not corrupt, and calculate additional dependencies that are not part of Slackware.

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

      Posté par Skilgannon le 10 février 2022 à 21:46. Évalué à 2.

      

      Merci pour la réponse complète, elle m’a éclairé sur pas mal de point.
      Pour le reste et pour être sure, il faudra que je teste la distribution.

  • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

    Posté par Yth (Mastodon) le 10 février 2022 à 08:59. Évalué à 10. Dernière modification le 10 février 2022 à 09:00.

    

    Slackware et Debian ont peut-être démarrée en parallèle, mais ces deux projets sont très différents.
    Là où avec Debian tu fais une installation minimale et tu ajoutes les outils dont tu as besoin, qui vont embarquer leurs dépendances avec eux, pour te faire un OS personnel, sous Slackware en général tu fais une « full install ».

    Les paquets Slackware sont séparés en catégories, par exemple :
    k - les sources du noyau Linux fourni par ailleurs ;
    kde - tout KDE
    xfce - tout XFCE
    t - texlive
    x - X.org / Wayland
    xap - outils nécessitant un serveur graphique
    n - outils réseau (apache, dovecot, dhcp, …)
    etc.
    Il est possible lors de l'installation de choisir chaque paquet un par un, mais en général on choisit l'option d'installation complète, ou on restreint par catégories.
    Par exemple sur un serveur sans interface graphique, on va inclure [a, ap, l, n, y]
    S'il faut les outils de développement on va rajouter d (gcc, autotools, git, etc.)

    Bref, pour installer sudo, une fois que tu as installé ta Slackware, ben tu ne fais rien, c'est dispo, tu ne tires pas de dépendances, tu ne cherches pas, c'est là, ça fonctionne.

    Le seule question qui se pose, c'est quid des logiciels qui ne sont pas disponibles.
    Et là tu as Slackbuilds.org, qui va te présenter la liste des dépendances, et si tu utilises un outil type sbotools, il va construire les dépendances, les installer et tout te faire jusqu'à ton paquet final.

    À noter qu'avec une base de Slackware complète, beaucoup de slackbuilds n'ont aucune dépendances (un grep vite fait me donne 60% sans dépendances, et 92% jusque deux dépendances).

    le gestionnaire de paquet n’intègre pas de résolution de dépendances

    Tu as donc le mauvais côté de la non gestion de dépendances : tu fais une installation complète, sans choisir précisément ce que tu veux, sinon tu te prends la tête à tirer tes dépendances à la main (personne ne fait ça je pense ?)
    Mais le bon côté aussi : aucun « dependency hell » pas de paquet à-la-con©®™ qui a un sous-utilitaire graphique que tu n'utilises pas mais qui va t'installer tout X.org, et Qt5, etc.
    Là tu vas avoir ton utilitaire ligne de commande, et aussi le sous-utilitaire graphique, c'est juste que ce dernier ne fonctionnera pas si tu as fait une installation pure console.
    Le Slackware ne te dira rien, ne te prendra pas la tête, ne t'avertiras pas non plus : tu fais comme tu veux.

    En pratique tu as juste la main sur ce que tu fais : installer deux versions de la même lib ? Pas de soucis, si ça te sert à quelque chose, ça va être un peu le bazar et certains liens symboliques de .so seront en conflit entre les deux, mais si c'est ce que tu veux, personne ne t'en empêche, et tu pourras toujours utiliser les pkgtools pour supprimer, réinstaller, modifier comme tu veux.

    Ça veut dire que tu peux parfaitement faire n'importe quoi et tout péter.
    C'est ce que j'attends de mon système d'exploitation : qu'il me laisse tout casser si c'est ce que j'ai envie de faire !

    D'ailleurs, fais gaffe, sous Slackware, un « rm fichier » ne te demande pas confirmation, tu n'es donc pas obligé de toujours écrire « rm -f fichier », et donc si « fichier » est protégé tu auras un avertissement visible, rare, et qui t'évites de faire des bêtises.

    • Yth.

    • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

      Posté par Renault (site web personnel) le 10 février 2022 à 13:22. Évalué à 4.

      

      Mais le bon côté aussi : aucun « dependency hell » pas de paquet à-la-con©®™ qui a un sous-utilitaire graphique que tu n'utilises pas mais qui va t'installer tout X.org, et Qt5, etc.
      Là tu vas avoir ton utilitaire ligne de commande, et aussi le sous-utilitaire graphique, c'est juste que ce dernier ne fonctionnera pas si tu as fait une installation pure console.

      Le problème n'est pas le mécanisme des dépendances, c'est le découpage des paquets qui n'est pas assez fin.
      Slack ne résout aucun problème en ce sens, si le paquet est mal fait, tu as le même problème, et si ta distribution avec dépendances gérées fait n'importe quoi il faut blâmer le mainteneur et pas le concept des dépendances automatiquement résolus.

      Le Slackware ne te dira rien, ne te prendra pas la tête, ne t'avertiras pas non plus : tu fais comme tu veux.
      En pratique tu as juste la main sur ce que tu fais : installer deux versions de la même lib ? Pas de soucis, si ça te sert à quelque chose, ça va être un peu le bazar et certains liens symboliques de .so seront en conflit entre les deux, mais si c'est ce que tu veux, personne ne t'en empêche, et tu pourras toujours utiliser les pkgtools pour supprimer, réinstaller, modifier comme tu veux.

      Mouais, je ne vois pas l'intérêt de la liberté de facilement faire de la merde. Je comprends l'intérêt du minimalisme et de ne pas avoir trop de restrictions, mais bon si c'est trop au détriment de l'utilisabilité ou juste pour pouvoir faire n'importe quoi mais rien de bien utile ne plus, je ne comprends pas l'intérêt.

      • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

        Posté par Yth (Mastodon) le 10 février 2022 à 15:59. Évalué à 10.

        

        Slack ne résout aucun problème en ce sens

        (Je préfère écrire Slackware en entier pour ne pas confondre avec Slack)

        Si, justement : les paquets n'ont pas ces découpes fines.
        Le choix de Debian c'est de tout découper finement : un paquet serveur, un paquet client, un paquet pour le dev, un paquet pour la doc, un paquet pour autre chose.
        Et puis à partir d'une seule source construire plein de paquets, gérer finement les dépendances, et n'installer que ce qui te sert effectivement à quelque chose.
        Ce qui a une très claire utilité pour un serveur le plus minimaliste possible (ou un conteneur type Docker).
        Et qui - globalement - ne te sert pas à grand chose sur ton poste de travail où tu vas finir par tout installer, bout par bout le jour où tu en as besoin, et où tu seras dépendant de ta connexion au dépôt de paquets pour pouvoir bosser.

        Le choix de Slackware c'est de ne pas découper.
        Il y a un code source pour mariadb par exemple, il y a un seul paquet, et tout dedans comme tu l'aurais avec un ./configure && make && make install.
        En contrepartie, un logiciel qui a une utilisation texte et une graphique, par exemple emacs, va venir complet même si tu n'as pas d'interface graphique. /usr/bin/emacs-no-x11 va fonctionner mais pas /usr/bin/emacs-with-x11.
        Et oui, tu vas avoir tout l'emacs graphique qui ne te sert à rien.
        Et c'est pas grave.
        Laisse de côté des quelques mégaoctets morts, le reste est plus simple à gérer.

        Mouais, je ne vois pas l'intérêt de la liberté de facilement faire de la merde.

        Parce que ce n'est pas forcément de la merde.
        Ce n'est pas parce que ce n'est pas de telle ou telle manière que les auteurs d'une distrib ont imaginés son utilisation, que ces façons de faire sont mauvaise.
        Oui, tu peux tout casser, mais être root permet de tout casser très très facilement.
        Je suis root sur toutes mes machines, j'ai rarement cassé grand chose, mais je vivrais très très mal de ne plus l'être parce que la distrib m'en empêche « pour mon bien » ou « par sécurité » !
        Bah voilà : je peux tout casser et tout réparer comme je l'entends, si je veux, ou je veux et comme je veux.

        Note bien : je suis très content de la gestion de dépendances Debian ou Redhat, quand je bosse sur des serveurs distants, souvent sous CentOS ces derniers temps, je trouve ça pratique de ne rien avoir à connaître du gestionnaire de paquet et juste faire yum install bidule.
        Mais sur mes machines, ça ne m'intéresse pas du tout.
        Dans un conteneur, je ne vois pas l'intérêt.

        Bref, c'est une particularité de Slackware, que j'apprécie à sa juste valeur, avec ses bons et ses mauvais côtés (je préfère gérer les mauvais côté de Slackware que ceux de Debian, question de goût), et je pense qu'il est important de le préciser parce que ça fait une grosse différence avec toutes les Debian/Redhat.

        • Yth.

        • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

          Posté par Renault (site web personnel) le 10 février 2022 à 16:58. Évalué à 5.

          

          Et qui - globalement - ne te sert pas à grand chose sur ton poste de travail où tu vas finir par tout installer, bout par bout le jour où tu en as besoin, et où tu seras dépendant de ta connexion au dépôt de paquets pour pouvoir bosser.

          J'installe rarement des paquets après l'installation de ma machine, si je dois l'installer c'est parce que je 'lai découvert et qu'il n'était pas déjà de base dans le système.
          Avec Slackware, c'est la même chose, tu découvrir un logiciel sympa pas déjà présent, tu dois le télécharger et l'installer…

          Il y a un code source pour mariadb par exemple, il y a un seul paquet, et tout dedans comme tu l'aurais avec un ./configure && make && make install.

          Pour que Slackware fasse ça, ils doivent avoir les dépendances de développement installés, dont des bibliothèques graphiques. ;)
          En fait tout le travail est fait, mais il manque l'étape du "on met dans la doc qu'il faut installer X" à "on installe X quand on veut Y automatiquement"… Le plus chiant est presque fait pour eux en fait.

          Dans un conteneur, je ne vois pas l'intérêt.

          Bah justement, c'est utile pour construire le conteneur avec le minimum d'outils en un minimum d'étapes.

          Mais sur mes machines, ça ne m'intéresse pas du tout.

          C'est comme tu veux de toute façon, mais je cherche la plu valu c'est tout.

          • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

            Posté par Yth (Mastodon) le 11 février 2022 à 11:00. Évalué à 7.

            

            Les dépendances de développement viennent directement avec la compilation/installation depuis les sources.
            En fait il faut faire un traitement spécifique manuel pour ne pas les inclure dans ton paquet.

            La Slackware est un ensemble complet et fonctionnel, si tu l'installes alors tout fonctionne dedans et tu as tout ce dont tu as besoin pour que tout fonctionne dedans.

            Ce (gros) bloc de base je l'aime bien parce que ça me simplifie la vie pour tout le reste : ce qui n'est pas inclus dans Slackware. Et j'aime l'équilibre : il y a beaucoup de choses mais pas tout et n'importe quoi, suffisamment pour faire presque tout ce que tu veux avec ta distrib sans rien ajouter, mais pas les besoins les plus spécifiques, ni toutes les alternatives possibles.
            Tu as Apache mais pas Nginx (ni thttpd, ou darkhttpd, etc.), ergo tu as un serveur web, mais pas toutes les alternatives possibles.

            Par exemple, je préfère utiliser PostgreSQL à MariaDB, or c'est MariaDB qui est inclus dans Slackware, mais installer PostgreSQL c'est un unique Slackbuild sans aucune dépendance.
            Or PostgreSQL a besoin de la glibc, readline, zlib, libxml2, libxslt, openssl, perl, python et tcl.
            Ces dépendances sont tellement utiles et standard pour un système Linux qu'elle sont juste là, tu n'as pas à chercher plus loin.

            Et donc, si j'ai une Slackware complète (ou que j'assume mon choix de sélectionner mes paquets à la main, comme je le faisais il y a 20 ans - oui je compilais mon noyau paramétré aux petits oignons aussi pour chacune de mes machines), j'ai simplement à vérifier les dépendances des Slackbuilds (à 92% 0, 1 ou 2 paquets, automatisé par les outils de build type sbotools), alors la gestion de dépendances dans le gestionnaire de paquets ne me sert à rien, elle ne m'apporte rien.

            Je suis d'accord qu'elle est utile pour construire un conteneur from scratch (une CFS ? 😀), mais dans le conteneur produit, c'est inutile, donc un autre moyen de générer ce conteneur pourrait remplacer un gestionnaire de paquets avec dépendances.

            Pour moi c'est la plus-value de la gestion de dépendances en dur qui m'échappe dans la majorité des situations.
            Et quand on voit l'enfer des autres systèmes de paquets avec gestion de dépendances complexes, type npm, composer, ou pip, et le bordel qu'ils provoquent, je ne suis pas sûr qu'il faille trop pousser le concept.
            Cela dit je ne crois pas que ce genre de problèmes soient présents avec yum ou apt.

            • Yth.

        • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

          Posté par Cyrille Pontvieux (site web personnel, Mastodon) le 14 février 2022 à 20:59. Évalué à 2.

          

          Bien expliqué.

          D’ailleurs je trouve le découpage à la lime à beurre de Debian un peu énervant.

          Tu installes un soft, mais non t’as pas tout le soft, et faut que tu devines parfois le ou les paquets qu’il faut que tu installes en plus pour avoir le soft complet (et non c’est pas toujours -dev)

          Sous ArchLinux je trouve le compromis intéressant. Les softs sont en général empaqueté en un seul paquet. Par contre les dépendances sont multiples :
          - obligatoire
          - optionnelles
          Et les optionnelles peuvent par exemple indiquer des trucs qui peuvent apporter des choses sans pour autant empêcher le soft de fonctionner.

          git sous ArchLinux vient avec tout compris (les man pages, les trads, . Par contre si on essaye de lancer gitk sans avoir installé les dépendances optionnelles, ça ne marche pas. C’est parce que tk est une dépendance optionnelle de git. Heureusement car sinon sur un serveur on tirerait tout X. Idem pour git gui qui dépend de tcl et tk.

          Faire des paquets séparés pour des entêtes ou des man pages, c’est complètement con. Ça quasi gagne rien en place disque et ça fait chier quand on n’a pas les paquets. En plus ça doit compliquer les mainteneurs de paquets.

          • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

            Posté par barmic 🦦 le 14 février 2022 à 22:33. Évalué à 6.

            

            C'est rigolo j'ai toujours entendu l'inverse comme critique de Debian que le découpage était trop large, qu'il installait trop de dépendances, que le choix d'installer par défaut les dépendances recommandées c'était bloated.

            Je ne comprends pas du tout la critique pour git. Par défaut le comportement est exactement celui que tu indique. Tu peux installer les paquets suggérés pour avoir plus ou ne pas installer les paquets recommandés pour avoir moins.

            En plus ça doit compliquer les mainteneurs de paquets.

            Hum ? Les mainteneurs sont très bien placés pour savoir si ça complexifie leur tâche. En soit pour ce genre de paquet c'est tout automatisé donc je pense que ça ne leur change rien et comme pour toi utilisateur ça ne change rien non plus (même si tu veut faire une installation sur une machine non connectée à internet apt pourra récupérer tous les paquets pour toi et dpkg les installera aussi facilement).

            A part une critique de principe parce que tu comprends pas pourquoi ils travaillent comme ça, je ne vois pas ce que ça te fais à toi utilisateur ?

            Bon ensuite si on regarde de plus prêt, le paquet git a un build par architecture alors que le paquet git-man est all architectures donc :

            • ça économise 1.7Mio * 9 pour les dépôts (+ le coût en téléchargement à chaque mise à jour à déployer sur les différents miroirs)¹
            • ça évite d'avoir des choses en double si tu fait du multiarch (généralement i386/amd64, mais tu peut en faire d'autres)

            Évidement si tu supporte une ou 2 archi (sans jugement moi je n'utilise que amd64, j'ai pas de besoin que la distribution que j'utilise tourner sur sparc) ou que tu fais de la distribution source avec un build à l'installation, tu fera peut être des choix différents.

            ---

            1. évidement on parle là 15Mio pour git mais si tu le fait pour chaque paquet tu peut avoir des gains substantiels ↩

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

      Posté par Gil Cot ✔ (site web personnel, Mastodon) le 10 février 2022 à 17:52. Évalué à 6.

      

      Il est possible lors de l'installation de choisir chaque paquet un par un, mais en général on choisit l'option d'installation complète, ou on restreint par catégories.
      Par exemple sur un serveur sans interface graphique, on va inclure [a, ap, l, n, y]
      S'il faut les outils de développement on va rajouter d (gcc, autotools, git, etc.)
      […] tu fais une installation complète, sans choisir précisément ce que tu veux, sinon tu te prends la tête à tirer tes dépendances à la main (personne ne fait ça je pense ?)

      Arf, je ne fais de « full install » que sur mes VM de test. Mon vieux portable Pentium sur lequel tourne Slackware a été installé en choisissant paquet par paquet et non par catégorie. ;-)

      À noter que la Debian permet aussi ce genre de chose : n'installer que certaines catégories (mais il y en a moins à l'installation, et plus quand on lance le gestionnaire de paquets en clicodrome) ou choisir les différents programmes (bon ça fait des lustres que je n'ai pas pas essayé et je ne sais pas si ça existe toujours, par contre on n'avait pas la liste de tout ce qui était possible mais juste un petit sous-ensemble que je pense issue des catégories disponibles à l'installation.)

      Tu as donc le mauvais côté de la non gestion de dépendances : tu fais une installation complète, sans choisir précisément ce que tu veux, sinon tu te prends la tête à tirer tes dépendances à la main (personne ne fait ça je pense ?)
      Mais le bon côté aussi : aucun « dependency hell » pas de paquet à-la-con©®™ qui a un sous-utilitaire graphique que tu n'utilises pas mais qui va t'installer tout X.org, et Qt5, etc.
      Là tu vas avoir ton utilitaire ligne de commande, et aussi le sous-utilitaire graphique, c'est juste que ce dernier ne fonctionnera pas si tu as fait une installation pure console.
      Le Slackware ne te dira rien, ne te prendra pas la tête, ne t'avertiras pas non plus : tu fais comme tu veux.

      La découpe des paquets est une chose et la gestion des dépendances une autre. Dans l'exemple que tu prends, il se trouve que les distributions Red Hat découpent aussi en gros, comme Slackware, mais avec la gestion de dépendance en plus : ça aide pour les usages domestiques (et les admins qui ne veulent pas avoir le temps de lire toute la doc de ce avec quoi le programme fonctionne et mettre les mains dans le cambouis pour lier les composants) en t'installant en plus le X.org ou le Qt5 etc. (du coup, quelques paquets on été revus pour être découpé en variante avec ou sans X, mais pas aussi finement que chez Debian)

      Une distribution est une philosophie/approche de l'administration système et autres facilités. La philosophie Slackware est d'être dans l'esprit des Unix initiaux (d'où la comparaison souvent avec les BSD) où les administrateurs font tout eux-même (à la mano, à leur sauce et non en se voyant imposer une vision) y compris pour les paquets (on récupère la totale telle que conçue par le projet puis on configure ce qu'on veut utiliser et on laisser le reste moisir à côté, là où les autres distributions veulent vous aider à tout prix.)

      À noter qu'avec une base de Slackware complète, beaucoup de slackbuilds n'ont aucune dépendances (un grep vite fait me donne 60% sans dépendances, et 92% jusque deux dépendances).

      Ça rejoint ce que je disais dans un autre message. Hormis les gens qui poussent le bouchon trop loin comme moi, il faut prendre le temps de regarder les dépendances pour les gérer mais on rarement une multitude (jusqu'à deux en général et aucun plus souvent, comme tu le montres)
      À l'usage, ça marche tellement simplement que tu te demandes parfois si les autres distros Linux n'ont pas inutilement compliqué… (mais je ne crois pas non plus parce-que certains choix amènent fatalement à plus de complexité)

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

      Posté par Skilgannon le 10 février 2022 à 22:55. Évalué à 1.

      

      Là où avec Debian tu fais une installation minimale et tu ajoutes les outils dont tu as besoin, qui vont embarquer leurs dépendances avec eux, pour te faire un OS personnel, sous Slackware en général tu fais une « full install ».

      Pour le coup je suis plus la philosophie Debian ou que même ArchLinux, qui est, il me semble encore plus extrémiste que Debian sur ce sujet.
      Dans mes vieux souvenirs quand on installe une Debian « bureau », certain logiciels qui ne sont pas liés à l’environnement de bureau sont aussi installés par défaut. Par exemple, comme sur Slackware visiblement Zenmap.
      Que l’on installe Thunar ou Nautilus ok, c’est lié aux environnements mais Zenmap ?
      En poussant le bouchon un peu trop loin (comme Maurice), ca m’étonne que qu’il ne soit pas possible d’installer seulement LibreOffice-Writer et Calc sans base ,draw , impress et math. Logiciels dont on se sert presque jamais sur son poste personnel.
      Et à l’inverse gnome-tweaks n’est pas inclus dans le meta-paquet Gnome (c’est pourtant un logiciel pour parametrer Gnome …) -_-"

      Pour les serveurs, je ne suis pas encore aller fouinner dans les paquets qui sont installé par défaut mais j'ai remarqué assez recaement que Cockpit l'était sur tout les CentOS et dérivés.
      Je pense pas qu'il soit compliqué de faire yum/dnf install cockpit.
      Car oui, il n'est quand même pas activé par défaut ouf!

      • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

        Posté par Yth (Mastodon) le 11 février 2022 à 11:11. Évalué à 4.

        

        Zenmap fait partie de nmap.
        Tu as zenmap parce que tu as nmap.
        Je ne sais pas si Debian découpe en deux paquets pour l'outil en ligne de commande et l'interface graphique, Slackware ne le fait pas.

        nmap c'est une commande réseau de base utile, pas pour tout le monde, mais néanmoins utile de manière générale. Comme dhcp : en réseau domestique tu peux très bien bosser avec des IP fixes, et perdre quelques Mo d'espace disque pour rien…

        Découper LibreOffice en ses différentes parties ?
        Bigre, c'est possible ? Il n'y a pas un tel socle commun que ça serait super compliqué et/ou sans réel intérêt ?
        On peut démarrer LibreOffice-Base et ouvrir un document Writer, un autre Calc, etc.
        Je ne crois pas qu'il s'agisse d'outils distincts, mais bien de plusieurs aspects d'un unique outil pour le coup…

        • Yth.

        • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

          Posté par Gil Cot ✔ (site web personnel, Mastodon) le 11 février 2022 à 12:33. Évalué à 2.

          

          Je ne sais pas si ça a changé, mais sur les sites de OpenOffice et LibreOffice il y avait bien un paquet (.deb ou .rpm) pour chaque composant… Et ce sont bien des outils distincts : un traitement de texte n'est pas un aspect de "[mettre le bon mot]" et un logiciel de présentation un autre aspect ; je peux à titre perso aimer utiliser Writer comme traitement de texte et préférer Gnumeric comme tableur par exemple. Une suite bureautique est bien distribué comme un seul produit mais fait d'un ensemble de programmes dixit Wikipédia, qui précise que certains programmes peuvent ne pas y être (IBM Domino Symphony et Microsoft Office pro incluent un logiciel de messagerie mais ce n'est pas le cas de LibreOffice.)
          La suite bureautique ne doit pas être confondu avec l'intégré bureautique comme Works qui malgré les apparences enregistre tout dans un format unique (qu'on fasse du traitement de texte ou du tableur dedans ce sera toujours du .wks —si j'ai bonne mémoire de l'extension.)

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

            Posté par Yth (Mastodon) le 11 février 2022 à 14:02. Évalué à 2. Dernière modification le 11 février 2022 à 14:03.

            

            Je ne dis pas que ça ne devrait, ou ne pourrait, pas être des outils séparés.
            D'ailleurs c'est bien plus philosophie UNIX de les avoir séparés.

            Mais il y a un binaire soffice.bin qui au bout du compte est appelé par les localc, lobase, lowriter, etc.
            Il n'y a qu'un seul logiciel LibreOffice, avec plusieurs modules, qui présentent une interface différente, et servent à gérer des types de fichiers différents, avec des formats différents.
            Et ça va même plus loin : si j'ai une fenêtre writer, une autre pour calc, une autre pour base, etc. ouvertes en même temps, je n'ai toujours qu'un seul processus soffice.bin qui tourne, et gère tout ça en parallèle !

            LibreOffice n'est pas composé de plusieurs outils juxtaposés.
            Et s'il y a des paquets distincts, il doit y avoir énormément de fichiers communs, et un même binaire répété plusieurs fois.
            Sauf si - peut-être ? - le code source permet de ne compiler et construire qu'un seul module à la fois, et qu'on peut répéter l'opération pour chacun, et avoir un binaire basé sur le même code source mais qui se restreint à une partie des possibilité.

            En d'autres termes : LibreOffice.writer est bien - en pratique - un aspect de LibreOffice, sisi.

            • Yth.

            • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

              Posté par Gil Cot ✔ (site web personnel, Mastodon) le 11 février 2022 à 16:26. Évalué à 2.

              

              Dans la liste des paquets il y en a qui sont communs/mutualisés, et je me souviens d'avoir installé un seul composant dans Debian. C'est en ce sens bien des programmes distincts et il a été prévu de pouvoir les compiler/distribuer séparément.
              Mais c'est une "suite" et quelque soit le programme le composant que tu installes, tu auras toujours ton processus soffice.bin (issu du paquet cœur-commun) qui sera lancé pour le gérer. Là dessus c'est mieux fait que du côté µ$ (mais pareillement, à l'époque où on installait la suite depuis un CD, on pouvait sélectionner de n'installer que certains "aspect" et pas d'autres et il n'y avait pas cette symbiose et mutualisation qu'on trouve dans LibreOffice. remarque, pendant longtemps les programmes ont été vendus séparément aussi.)

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

            • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

              Posté par Gil Cot ✔ (site web personnel, Mastodon) le 11 février 2022 à 16:51. Évalué à 2. Dernière modification le 11 février 2022 à 16:51.

              

              En complément à mon précédent message, voir par exemple la page du HowTo de vitux.com avec cette image…
              
              …où on note libreoffice-core (c'est lui qui contient soffice.bin et d'autres) et libreoffice-common (là je crois que ce sont d'autres "ressources" mutualisées —dans /usr/share/ donc) qui sont toujours installés.
              Pour une utilisation normale/standard, le programme est appelé à travers le gestionnaire, par exemple libreoffice -writer. Cela peut faire penser à un « aspect » mais en fait on peut lancer le programme seul, avec lowriter pour reprendre le même exemple avec des options utiles pour travailler en mode headless.

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

              • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

                Posté par jyes le 11 février 2022 à 18:49. Évalué à 4.

                

                Cela peut faire penser à un « aspect » mais en fait on peut lancer le programme seul, avec lowriter pour reprendre le même exemple

                Sauf que "lowriter" est un script qui lance "/usr/lib/libreoffice/program/soffice --writer". À la fin il n’y a bien qu’un seul programme "soffice.bin" qui fait tout tourner. Cependant, les modules (Calc, Base, Impress, etc) contiennent beaucoup de choses dont des bibliothèques. Donc même s’il a y un seul exécutable, il y a bien une distribution binaire différente pour les différents modules. Plus que des « aspects », ce sont de (gros) « plugins ». Mais ça ne me choque pas qu’on distribue les plugins à part, c’est bien l’intérêt de leur modularité par rapport à un exécutable lié statiquement avec tout dedans.

  • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

    Posté par raphj le 10 février 2022 à 12:45. Évalué à 10. Dernière modification le 10 février 2022 à 12:49.

    

    1) et aussi, un peu, car le machin-d’init-qui-fait-tout-et-presque-le-café m’agace, pas très Unix dans le sens : « je fais une seule chose, mais je la fais bien » tout cela !

    Je suppose que tu parles de systemd. Je ne comprends pas cet avis. Ou plutôt, je comprends que c'est une rengaine souvent colportée sans trop réfléchir et une (mauvaise) manière de justifier de la haine contre systemd.

    On encense les systèmes BSD pour leur bonne intégration. Justement, systemd c'est un ensemble bien intégré d'outils qui font chacun une chose bien. Ce n'est pas du tout un truc monolithique qui fait tout. Il apporte des qualités à l'écosystème GNU/Linux qu'on prêtait aux *BSD ! :-)

    L'init n'est qu'un des nombreux petits outils qui font une seule chose et bien fourni par le projet systemd. Faut voir systemd comme GNU : un ensemble d'outils cohérents. Qui apporte une uniformisation, y compris à travers les différentes distributions, à un bazar pénible et spécifique qui régnait avant son arrivée.

    Je trouve l'administration un poste sous Linux beaucoup plus simple et cohérente depuis l'introduction de systemd qui fait bien son job. Justement, tout est bien propre et découpé.

    Si tu éprouves un sentiment aussi fort que l'agacement, c'est que tu as réfléchi sérieusement au problème et que tu vois une autre manière de faire meilleure. Quelle alternative vois-tu ? (en la décrivant précisément, et sans, du coup, tomber sur une description d'un équivalent à systemd).

    • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

      Posté par Yth (Mastodon) le 10 février 2022 à 16:16. Évalué à 10.

      

      A mon sens, il n'y a aucune haine envers systemd chez Slackware.
      Mais comme je l'ai écrit dans la dépêche : c'est très disruptif, il faut changer toute la façon d'administrer sa machine, de gérer les services, d'aller chercher les logs, etc.

      Comme tu le dis toi-même : il faut voir systemd comme GNU, et bien Slackware n'est pas une distribution systemd/Linux, mais GNU/Linux.
      À la fois par tradition, et parce que ça convient à toute la communauté.

      Ce qui fait beaucoup crier les gens autour de systemd c'est son côté hégémonique et prosélyte : les utilisateurs de Debian ou Redhat (et dérivées) se sont vus imposer de changer leur façon d'administrer leur machine, du jour au lendemain, sans avoir tellement le choix, parce qu'il est difficile de mettre ce truc là en option, ou de l'activer quand on veut, c'est tout ou rien, sans douceur.

      Ben voilà, sous Slackware t'as tout, mais sans rien de systemd.
      Et c'est un choix qui définit autant la distribution que celui de fournir XFCE/KDE mais pas Gnome.

      Je trouve l'administration un poste sous Linux beaucoup plus simple et cohérente depuis l'introduction de systemd qui fait bien son job. Justement, tout est bien propre et découpé.

      Je vais troller un peu (un peu, promis !), mais je pense que c'est parce que tu avais auparavant à administrer des Debian (ou Redhat ou dérivés), et qu'ils foutaient historiquement un bazar monstre et incompréhensible dans /etc pour permettre à des outils en clicodrôme d'administrer avec des gros boutons et des icônes colorées. Tu avais deux choses à apprendre : la façon de faire Debian et les spécificités de chaque logiciel.

      Sous Slackware tu as les fichiers de conf des auteurs des logiciels, disponibles là où la doc officielle les place.
      Et franchement, ça n'a rien ni de bordélique, ni de spécialement complexe.
      Il faut juste éditer tes fichiers texte à la main, et lire la doc des auteurs des logiciels.

      Systemd résout (aussi) des problèmes de Debian et de Redhat, un bon outil se contenterait de résoudre des problèmes de Linux.
      En fait, je vois systemd comme une évolution de la philosophie d'administration système Linux développée ces (presque) trente dernières années par Debian et Redhat (qui se sont pas mal repompés leurs idées).
      Et comme la philosophie Slackware n'a jamais suivi cette voie là, systemd y a nettement moins d'intérêt.

      • Yth.

      • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

        Posté par Renault (site web personnel) le 10 février 2022 à 18:55. Évalué à 5.

        

        Ce qui fait beaucoup crier les gens autour de systemd c'est son côté hégémonique et prosélyte : les utilisateurs de Debian ou Redhat (et dérivées) se sont vus imposer de changer leur façon d'administrer leur machine, du jour au lendemain, sans avoir tellement le choix, parce qu'il est difficile de mettre ce truc là en option, ou de l'activer quand on veut, c'est tout ou rien, sans douceur.

        La question est pourquoi ça a été fait comme ça : maintenir des outils en parallèle c'est possible mais pénible, ça demande des efforts d'intégration, de tests, etc. Et à l'ancienne tu avais des scripts init à leur sauce, des astuces qui divergent entre les distributions et logiciels, etc. Les mainteneurs ont globalement sauté sur un outil pratique pour simplifier leur travail.

        Si les gens veulent maintenir la méthode à l'ancienne, comme c'est libre ils se mettent en commun pour le faire ou utiliser une autre distribution. ;) Debian et Red-Hat ne doivent pas se plier aux exigences de tout le monde. Les utilisateurs délèguent la gestion de la base du système à ces équipes qui font des choix en permanence, dont systemd.

        Donc reprocher que ces équipes ont fait des choix pour les utilisateurs c'est fort le café : c'est le principe même d'une distribution, sinon tout le monde prend une LFS et se débrouille avec.

        Je vais troller un peu (un peu, promis !), mais je pense que c'est parce que tu avais auparavant à administrer des Debian (ou Redhat ou dérivés), et qu'ils foutaient historiquement un bazar monstre et incompréhensible dans /etc pour permettre à des outils en clicodrôme d'administrer avec des gros boutons et des icônes colorées. Tu avais deux choses à apprendre : la façon de faire Debian et les spécificités de chaque logiciel.

        Mouais pas vraiment.

        Le soucis des scripts init à l'ancienne c'est qu'il n'y avait pas de standard.
        Tu as certains mainteneurs qui vont gérer des cas courant différemment des autres, voire penser (ou pas) à l'existence de SELinux par exemple, et autres… Du coup tu as plein de manières de faire qui se mélangent, que ce soit au sein d'une distribution ou entre les logiciels eux mêmes quand ils fournissaient leur script init maison.

        Du coup là encore, dire que tout est uniforme sans systemd c'est là aussi un peu aberrant, car c'est sans doute l'avantage numéro 1 de systemd.

        Sous Slackware tu as les fichiers de conf des auteurs des logiciels, disponibles là où la doc officielle les place.
        Et franchement, ça n'a rien ni de bordélique, ni de spécialement complexe.
        Il faut juste éditer tes fichiers texte à la main, et lire la doc des auteurs des logiciels.

        Le problème est justement le manque d’uniformité et la nécessité de se plonger dedans à chaque fois…

        Systemd résout (aussi) des problèmes de Debian et de Redhat, un bon outil se contenterait de résoudre des problèmes de Linux.
        En fait, je vois systemd comme une évolution de la philosophie d'administration système Linux développée ces (presque) trente dernières années par Debian et Redhat (qui se sont pas mal repompés leurs idées).

        Je ne vois pas quels problèmes Debian et Red-Hat ont spécifiquement introduits mais bon. Ni en quoi les solutions retenues sont moins Linux que les autres.

        Et comme la philosophie Slackware n'a jamais suivi cette voie là, systemd y a nettement moins d'intérêt.

        L'intérêt de systemd ne dépend pas tellement de la distribution en dessous. Typiquement mon projet embarqué est techniquement une distribution sur mesure (on est loin de Red-Hat et Debian) et pourtant il y a systemd et ça a un avantage énorme par rapport à avant. :)

        • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

          Posté par Yth (Mastodon) le 11 février 2022 à 11:32. Évalué à 10.

          

          J'avais prévenu que ça partait en troll hein :)

          Mais bon, il y en a d'autres des systèmes d'init, qui résolvent le principal grief fait à systemV (qui n'est pas le système d'init de Slackware, on est plus sur un truc BSD compatible systemV) c'est à dire le démarrage de services en parallèle, pour avoir un système opérationnel plus rapidement (et la gestion de dépendances, là encore tiens !).

          Aucun n'a fait autant jaser.
          Et c'est lié à l'approche « je suis La Solution, virez tout le reste et ne laissez que Moi ! » du projet.
          Et de multiples erreurs de communications comme d'envoyer chier les gens qui s'étonnaient que screen se fasse tuer par systemd.

          Comment tu peux apprécier l'approche d'un développeur principal qui répond des choses du genre « bah c'est pas comme ça que je fais les choses, donc je m'en fous » ? Ok, c'est son logiciel, il le fait comme il veut, mais à un moment, si le logiciel est utilisé, ben tu peux plus.

          Donc le projet est parti avec une réputation de merde, il casse des trucs qui fonctionnaient avant, oblige à changer ses habitudes et en apprendre de nouvelles, pour ne pas apporter forcément plus que ce que d'autres projets apportaient déjà.
          C'est peut-être bien, mais tant que ça ne reste pas une obligation, et qu'on a le choix, on le prend…

          • Yth.

      • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

        Posté par Misc (site web personnel) le 11 février 2022 à 00:18. Évalué à 4.

        

        Mais comme je l'ai écrit dans la dépêche : c'est très
        disruptif, il faut changer toute la façon d'administrer sa
        machine, de gérer les services, d'aller chercher les logs,
        etc.

        Systemd est présent depuis 2 versions de RHEL (cad sur toutes les versions supportés de la distro, sauf pour les clients avec un contrat étendu pour RHEL 6). C'est aussi par défaut dans toutes les versions supportés de Debian, et dans toutes les version d'Ubuntu sauf la 14.04, qui est encore supporté avec un contrat par Canonical.

        Donc je pense que depuis le temps, l'argument commence à dire plus sur l'incapacité de s'adapter d'une partie des utilisateurs qu'autre chose.

        Et l'exode promise vers les *BSD ne s'est pas vraiment produite.

        Je n'ai aucun souvenir de protestations sur le passage d'iptables vers nftables ou pour le changement de ifconfig vers iputils (ou de lilo vers grub, d'un FS X vers un FS Y style zfs/btrfs, etc, etc).

        Ce qui fait beaucoup crier les gens autour de systemd c'est
        son côté hégémonique et prosélyte : les utilisateurs de Debian
        ou Redhat (et dérivées) se sont vus imposer de changer leur
        façon d'administrer leur machine, du jour au lendemain, sans
        avoir tellement le choix, parce qu'il est difficile de mettre
        ce truc là en option, ou de l'activer quand on veut, c'est
        tout ou rien, sans douceur.

        Hop la, tranquille la réécriture de l'histoire.

        Pour Debian, il y a eu facile 1 à 2 ans de débats houleux, une période de transition et visiblement, personne n'a été motivé pour maintenir les alternatives, sauf devuan qui ne decolle pas vraiment. On peut comparer les 4000 machines remontées à l'instance popcon de Devuan avec les 210 000 sur l'instance popcon de Debian. C'est quand même 2 à 3 ordres de grandeur plus grand.

        Donc on repasseras sur "imposer du jour au lendemain" et "sans douceur".

        Pour Fedora, (et donc RHEL/Centos par la suite), ça a aussi été discuté et fait de manière public, via la liste de discussion. Il y a aussi eu des aménagements comme le fait de garder la commande service pendant longtemps, la compatibilité avec les fichiers d'init, le fait que les logs sont restés longtemps dispo via tail comme avant, etc.

        Donc on repasseras aussi pour le "sans douceur".

        Encore une fois, curieusement, il y a personne qui a crié comme ça pour le passage à Upstart, qui était tout aussi ambitieux en 2006 (fusionner at/cron et init, par exemple) et qui était aussi bien parti pour être mis en place partout (sur Fedora, sur Debian, on avait commencé à en parler pour mageia et aussi sur opensuse, et bien sur, c'était déjà sur Ubuntu).

        Et quand je dit "personne n'a crié", je veux évidement dire "à ma connaissance, personne n'a laissé de message de menace sur le répondeur perso d'un mainteneur de Upstart". Je peux pas en dire autant pour systemd, et c'est pas franchement le moment le plus glorieux de la communauté du logiciel libre.

        Et je ne sais pas pourquoi, c'est pas le sujet qui ressort le plus quand ça parle de systemd.

    • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

      Posté par PR le 10 février 2022 à 18:43. Évalué à 1.

      

      Ce n'est pas du tout un truc monolithique qui fait tout.

      Tu pourrais faire un truc pour moi ? Un truc que j’ai oublié de faire quand je l’ai viré de mon système parce qu’il me tirait encore et toujours plus de dépendances.

      $ ls -lLh /sbin/init /sbin/shutdown /usr/sbin/atd /usr/sbin/xinetd /sbin/udevd
      -rwxr-xr-x 1 root root   52K Jan  9 11:17 /sbin/init*
      -rwsr-xr-- 1 root super  31K Jan  9 11:17 /sbin/shutdown*
      -rwxr-xr-x 1 root root  1.2M Jan  9 11:04 /sbin/udevd*
      -rwxr-xr-x 1 root root   23K Jan 29 12:46 /usr/sbin/atd*
      -rwxr-xr-x 1 root root  171K Dec 20 23:32 /usr/sbin/xinetd*
      
      

      Je te laisse deviner l’intrus… qui est de facto un programme de chez systemd :

      $ equery m udev
       * sys-fs/udev [gentoo]
      Maintainer:  systemd@gentoo.org
      Upstream:    Remote-ID:   cpe:/a:kernel:udev ID: cpe
                   Remote-ID:   systemd/systemd ID: github
      Homepage:    https://www.freedesktop.org/wiki/Software/systemd
      

      La même mais avec les programmes systemd, ça donne quoi ?

      Mort aux cons !

    • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

      Posté par Skilgannon le 10 février 2022 à 23:56. Évalué à 7.

      

      Je suppose que tu parles de systemd. Je ne comprends pas cet avis. Ou plutôt, je comprends que c'est une rengaine souvent colportée sans trop réfléchir et une (mauvaise) manière de justifier de la haine contre systemd.

      Si tu éprouves un sentiment aussi fort que l'agacement, c'est que tu as réfléchi sérieusement au problème et que tu vois une autre manière de faire meilleure. Quelle alternative vois-tu ? (en la décrivant précisément, et sans, du coup, tomber sur une description d'un équivalent à systemd).

      Oula Oula, oui je parle bien de systemd, mais je n'ai pas de haine envers lui ou ces créateurs. J'ai par ailleurs une sainte horreur des extrémistes de tout poile. Et y avoir réfléchi oui sûrement, mais « sérieusement »", ça reste encore à prouver :)

      Ceci étant dit, ce n'est pas systemd en lui-même qui m’agace, il est très pratique et s’il a en plus un peu uniformisé le bazar pénible qui régnait je ne peux que applaudir.

      En revanche, d'après ce que j'ai compris il s'occupe de la gestion des services et de l'init (qui est grosso-merdo que le fait de lancer des « services » dans le bon ordre (c'est réducteur je sais)). Et pour moi il devrait faire que cela.
      Du coup pourquoi, systemd comporte des composants du style
      - systemd-logind
      - systemd-networkd
      - systemd-resolved
      - systemd-timesyncd

      En quoi ces composants sont de la gestion de services ?
      Ou alors je n'ai pas compris ce que était systemd.
      Si c'est un environnement, au sens « environnement de bureau » par exemple, alors je viens comprendre cela, mais dans ce cas je voudrais pouvoir ne pas installer systemd/Timers et pouvoir utiliser cron.

      Bref, c'est plus la philosophie qui est derrière que je comprends pas, et quand je comprends pas quelque chose je m’agace.

      (Bref)² , on parlait de Slackware au départ, et on / j’ai diverge/é … et ca fait beaucoups!

      Heu … oui, ok la porte, je → []
      voila

      • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

        Posté par Misc (site web personnel) le 11 février 2022 à 00:45. Évalué à 3.

        

        En quoi ces composants sont de la gestion de services ?

        Alors je vais me permettre de te pointer vers les discussions d'il y a 8 ans sur le sujet:

        https://linuxfr.org/nodes/97210/comments/1426821

        Si c'est un environnement, au sens « environnement de bureau »
        par exemple, alors je viens comprendre cela, mais dans ce cas
        je voudrais pouvoir ne pas installer systemd/Timers et pouvoir
        utiliser cron.

        Tu peux, il suffit d'installer cron. Sauf erreur de ma part, les timers sont gérés en interne dans systemd (eg, dans le processus d'init), donc tu peux pas les retirer (tout comme tu peux pas retirer le support du dimanche dans cron). La raison est que mettre ça dans un processus à part n'apporterais rien à part de la complexité inutile (eg, communication entre le processus qui sert pour les timers et qui doit tourner à vide pour rien pour simplement signaler au systéme d'init de lancer un service).

        Et je rappelle que les timers font des choses que cron ne fait pas de base, et je parle pas juste de la lisibilité. Mais par exemple, la limitation des ressources (utiles pour les backups), le fait de disperser les exécutions (utiles pour pas lancer 150 mises à jours à la même seconde), la gestion comme anacron pour le cas ou ta machine est éteinte, etc.

        Et contrairement à vixie cron, la dernière release n'a pas l'age de voter en France depuis 1 mois.

  • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

    Posté par ff9097 le 10 février 2022 à 17:30. Évalué à 2.

    

    1) et aussi, un peu, car le machin-d’init-qui-fait-tout-et-presque-le-café m’agace, pas très Unix dans le sens : « je fais une seule chose, mais je la fais bien » tout cela !

    Il ne fait pourtant qu'une chose : il gère ta machine

    • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

      Posté par jyes le 11 février 2022 à 11:12. Évalué à 5.

      

      Ah, je croyais c’était le rôle du noyau, … ah non, celui de Compiz, ou celui mon administrateur système. Je ne sais plus. « Gérer ma machine » c’est tellement clair comme définition.

      • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

        Posté par ff9097 le 11 février 2022 à 20:08. Évalué à 4.

        

        Visiblement le second degré a du mal à passer ici aussi.

        • [^] # Commentaire supprimé

          Posté par Anonyme le 14 mars 2022 à 09:25. Évalué à 4. Dernière modification le 14 mars 2022 à 09:26.

          

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

  • [^] # Re: Slackware n’intègre pas de résolution de dépendances ?

    Posté par Lutin le 14 février 2022 à 10:44. Évalué à 3.

    

    Pourquoi pas tenter Gentoo ?

  • [^] # Commentaire supprimé

    Posté par Anonyme le 14 mars 2022 à 09:19. Évalué à 2. Dernière modification le 14 mars 2022 à 09:21.

    

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

• # "le monde Linux s’éloigne lentement mais sûrement de la philosophie UNIX"

  Posté par Christophe Duparquet (site web personnel) le 10 février 2022 à 17:24. Évalué à 2.

  

  Un petit lien pour en savoir plus ?

  « J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »

  • [^] # Re: "le monde Linux s’éloigne lentement mais sûrement de la philosophie UNIX"

    Posté par Yth (Mastodon) le 11 février 2022 à 10:38. Évalué à 10.

    

    Bah c'est le ressenti de Patrick Volkerding, il s'agit ici d'une citation directe.
    Elle est dans la ligne du traditionalisme Slackware qu'on pourrait traduire par : « fais chier de désapprendre un truc simple et qui fonctionne pour en apprendre un autre moins simple, même s'il fonctionne aussi ».
    A saupoudrer de « ce que je connais est forcément plus simple que ce que je ne connais pas, si le service rendu est le même ».

    • Yth.

    • [^] # Re: "le monde Linux s’éloigne lentement mais sûrement de la philosophie UNIX"

      Posté par PR le 11 février 2022 à 11:43. Évalué à 1.

      

      C’est dans le nom :

      Gnu is Not Unix / LINUx

      Mort aux cons !

• # Distrowatch review

  Posté par j (site web personnel) le 14 février 2022 à 19:19. Évalué à 3.

  

  http://distrowatch.org/weekly.php?issue=20220214#slackware

  • [^] # Re: Distrowatch review

    Posté par tisaac (Mastodon) le 14 février 2022 à 21:41. Évalué à 2.

    

    Deux choses que je retiens ou plutôt qui m'interpelle:

    L'hypothèse d'une communauté créée il a plus de 20 ans mais qui n'est depuis rejoint par pratiquement personne

    It suggests to me not many new people have wandered into the Slackware community in the past 20 years and, given the project's apparent intent to avoid evolution, I suspect not many newcomers are going to try out Slackware and stick with it.

    Un KDE très économoe

    When signed into the KDE Plasma desktop memory consumption rose to around 350MB. This makes Slackware's Plasma session one of the lightest in memory I've run.

    Cela donne quoi sur les autres distributions ? J'avais en tête des ordres de grandeur bien plus important, style 800MB mais j'imagine que je me trompe, non ?

    Surtout, ne pas tout prendre au sérieux !

    • [^] # Re: Distrowatch review

      Posté par Psychofox (Mastodon) le 15 février 2022 à 13:08. Évalué à 9.

      

      J'ai 881MB d'utilisé sur une Fedora Jam KDE edition. Mon autre laptop sous Fedora avec Gnome utilise 1.2GB avec juste un terminal ouvert.

      Cela étant dit, je crois que c'est pas vraiment le Plasma de slackware qui est léger mais tout le bordel qui se charge avant (et après pour la gestion des packets par exemple):

      Vérifié sur un tty j'ai 600MB utilisé avant même de me logger sous kde, avec juste KDM ouvert sur la Fedora Jam et 660MB utilisés avec GDM avant de me logger sous gnome donc il y a déjà un usage mémoire conséquent avec systemd, networkmanager, et les quelques services par défaut (cups, firewalld, blutooth, chrony, polkit, power/thermal, etc). La différence entre mes deux laptops avant de me logger sur le bureau vient essentiellement de docker/containerd et openssh qui ne sont pas installé et activés sur ma Fedora Jam. Une autre VM sous Fedora avec i3 (+dmenu, i3bar, i3status) utilise 750MB avec juste un terminal.

      Bref je crois que c'est l'absence de systemd et peut-être d'autres services non activés automatiquement qui fait la légèreté de ce bureau Slackware plus qu'une configuration particulière de Plasma.

  • [^] # Re: Distrowatch review

    Posté par Yth (Mastodon) le 26 février 2022 à 17:11. Évalué à 10.

    

    Je suis partagé sur cette évaluation, mais bon, je n'ai pas l'habitude de lire les trucs sur distrowatch…

    The distribution is a slow moving project, often with several years between releases.

    Cette distribution évolue lentement, avec souvent plusieurs années entre deux versions.

    Cette distribution a deux versions : une stable qui sort quand elle est prête (un peu comme Debian), et une rolling-release très active.
    En 27 années et demi il y a eu 13 versions stables de Debian et 36 versions stables de Slackware.
    On voit clairement un changement de rythme depuis la 14.1 (2,5 années) et la 14.2 (5,5 années), mais souvent il y a entre six mois et un an entre deux versions, pas « several years ».

    Bon, c'est un brin agaçant quand on commence par des âneries, j'aurais pu lire un truc comme « on croyait que ça n'avançait plus vu que le rythme habituel a été dépassé de 5 ans, ce qui est très long en informatique », mais en vrai, jusqu'à la 14.1, c'était un projet plutôt rapide est dynamique.
    Je ne peux qu'espérer que ça redevienne le cas.

    Slackware has a well deserved reputation for stability
    and for having a simple technical design.
    A design which frequently ignores modern approaches to system management.
    Slackware still uses a text-based system installer,
    has 90s-era approaches to package management,
    and prefers editing text files over graphical tools when it comes time to adjust most configuration settings.

    Slackware a une réputation mérité de stabilité
    et d'avoir un design simple/épuré.
    Un design qui ignore généralement les approches modernes de l'administration système.
    Slackware continue d'utiliser un installateur en mode texte.
    a une approche très années 90 de la gestion de paquets,
    et choisit l'édition textuelles de fichiers plutôt que des outils graphiques pour la configuration plus fine.

    J'ai encore une fois le sentiment que « ignorer les approches modernes de l'administration système » est juste une façon de dire qu'il n'y a pas systemd. On en pense ce qu'on veut, mais je ne vois toujours pas systemd comme un passage obligé, ni un truc si révolutionnaire que ça. Bref, passons…

    Concernant l'installateur en mode texte, fichtre, mais et alors ?
    C'est l'outil pour installer le système, le truc que tu vois une fois par nouvel ordinateur, le reste se fait en mise à jour, et on ne revoit plus jamais cet installateur.
    Comme si, pour être « moderne », il fallait absolument avoir un outil à l'utilité marginale en version graphique ?
    Alors que le seul intérêt d'un tel outil est de faire bonne impression pour un public de néophytes.
    Que de préjugés alors…

    Le gestionnaire de paquets de Slackware date des années 90.
    Mais bon, dpkg date de 1994, RPM de 1997 (1995 en interne chez Redhat), ce sont aussi des gestionnaires de paquets datant des années 90.
    Tous les trois ont évolués depuis, il y a eu des versions pour chacun d'entre eux, et il existe des outils plus haut niveau pour l'administration des paquets, pour les trois, y compris des interfaces graphiques (oui oui, même pour Slackware !).
    Donc : critique ou gage de qualité ? Ou rien à voir avec la choucroute ?

    Et la dernière phrase est juste, sous Slackware l'approche éditeur de texte dans un terminal est préférée à l'approche cliquesque, c'est à dire la façon de faire pour la majorité des serveurs : on n'accède pas à un outil graphique pour administrer un serveur, mais on le fait avec un vi/nano/joe quelconque à travers SSH.
    Et même en 2021 on continue de faire des erreurs de copié-collé liés à des sauts de ligne probablement liés à l'utilisation de ce genre d'outils en ligne de commande via SSH… Je doute que Facebook utilise beaucoup de Slackware.
    Encore une fois on n'a pas ici affaire à des outils très orientés néophytes.
    Cela dit je ne critiquerait pas un outil de configuration graphique, mais sous Slackware il y a ce genre d'outils en ncurses, donc en terminal, mais graphique, dans la lignée de l'installeur, ils fonctionnent très bien via SSH.

    Bref, à retenir : Slackware ne subit pas les hypes, suit sa propre voie, et privilégie l'apprentissage des fichiers de configuration à l'utilisation d'un outil graphique qui essaierait de centraliser tout, ce qui fait qu'on a une impression d'austérité et un franc manque de bling-bling.

    Il y a pas mal de choses à l'avenant : si Slackware utilise un logiciel qui fait le taf, mais que d'autres plus grosses distribs ont remplacées par une alternative, qui fait le taf aussi, Slackware est considérée comme « en retard » plutôt que différente.
    C'est très marquant avec l'opposition Calligra/LibreOffice.
    Il y a des tas de gens qui se font chier à coder un logiciel efficace, léger, rapide, et parfaitement intégré à l'environnement KDE, j'ai nommé Calligra, mais comme le logiciel phare de bureautique c'est LibreOffice, point de salut, Slackware est à la ramasse de proposer le premier plutôt que le second !
    Alors : il est très simple d'installer LibreOffice sous Slackware, et comme l'environnement de bureau par défaut est KDE (ou XFCE), Calligra est un choix par défaut assez évident : ça s'intègre bien, ça se lance vite, et ça fait l'essentiel du boulot, en odt/ods/od* comme LibreOffice, et c'est capable d'ouvrir des fichiers .docx comme LibreOffice.
    Il faut vraiment avoir un usage un peu avancé de la suite bureautique pour trouver des différences fortes, ou des manquements, et dans ce cas là, tous les gens que j'ai rencontré avec ce genre de besoins, décrient LibreOffice est se tourne vers MS Office, à mon grand dam…

    De la même manière, je n'ai rien contre VLC, mais critiquer son absence c'est un brin orienté…
    Je n'aime pas spécialement utiliser VLC, réfractaire à l'interface, je préfère largement smplayer.
    Historiquement, mplayer a toujours été le lecteur vidéo qui permettait de lire tout et n'importe quoi, avant le début du projet VLC, c'est toujours actif, toujours fonctionnel, ça marche au poil, encore une question de choix ici ? VLC ou la déshérence ?

    The distribution ships with so many applications it's difficult to find anything in the menus because each category in the twin-pane menu holds pages of launchers. Many of these programs I haven't used before, or have not used in a long time.

    La distribution embarque tellement de logiciels qu'il est difficile de s'y retrouver, chaque catégorie de menu a plusieurs pages de lanceurs. Avec beaucoup de programmes que je n'ai jamais utilisé, ou pas depuis longtemps.

    Mouais, bref, il n'y a pas exactement les outils dont il a l'habitude et il est tout perturbé ?
    Il y a du choix.
    Autant pour la soi-disant austérité de la distribution : en full-install elle n'est pas minimaliste, et offre du choix pour un peu tout. En vrai, je trouve ça absolument génial pour un néophyte (que j'ai été), pour tout essayer, découvrir, apprendre, expérimenter.

    I find it too much effort to get common tasks done with this distribution. There is a lot of manual work involved and very little, if any, benefit to being forced to do this extra work.

    Je trouve qu'il faut trop d'efforts pour accomplir la moindre tâche avec cette distribution. Il faut beaucoup d'huile de coude pour très peu, voire pas, de valeur ajoutée.

    C'est un peu ce que je ressens quand je dois me faire ch… avec une VM CentOS, pourquoi tant d'efforts pour des tâches simples ? pourquoi tant de commandes à retenir par cœur (ou à avoir dans sa cheat sheet) ?

    Mais qui est le problème ? Moi, l'amateur d'une distribution fidèle, moderne et conservatrice à la fois, qui « fait les choses comme il y a 25 ans » qui suit campé sur mes habitudes, ou plutôt l'auteur de l'article qui a une vision des « bons logiciels à utiliser », des façons de faire, et ne comprends pas que Slackware puisse penser les choses différemment ?

    Bref, je trouve cet article triste, très monoculturel, je trouve que l'auteur pousse à rejeter la Slackware non pas sur ses défauts, mais sur des choix qui ne sont pas jugés assez mainstream…

    Un dernier point concernant la communauté, qui serait stagnante depuis 20 ans.
    Ce n'est pas ce que je ressens dans le projet Slackbuilds, ça tourne, des gens vont, d'autres viennent, il y a plusieurs dizaines de contributeurs assidus et réguliers, et il n'est pas si commun de trouver un logiciel libre pour lequel c'est le cas.
    Je le déplore mais il y a beaucoup plus de contributeurs au simple projet Slackbuilds.org qu'à Gimp, qui a, à mon avis, une importance nettement supérieure pour le monde des logiciels libres.
    J'en suis ravi pour la Slackware, et les Slackbuilds, bien sûr, et je ne jetterai pas la vieille bique avec l'eau du temps, cette distribution a un avenir, et continuera de proposer une alternative fiable aux projets équivalents et plus mainstream que je trouve souvent trop pressés d'intégrer les dernières hypes du moment, au détriment d'autres projets tout aussi valables mais moins bien marketés.

    • Yth.

    • [^] # Re: Distrowatch review

      Posté par Gil Cot ✔ (site web personnel, Mastodon) le 02 mars 2022 à 21:09. Évalué à 3.

      

      Bof, c'est typiquement le genre d'articles qu'écriraient des usagers de Fenêtre qui se frottent pour la première fois à Nunux et qui ne veulent pas avouer leur incapacité… C'est aussi le genre de chose qu'on écrit quand on cherche à cracher à tout prix sur une distro qui n'est pas la sienne et considérée avec œillères que c'est la seule valable : qui veut noyer l'alternative l'accuse de tout et n'importe quoi. Aujourd'hui c'est VLC qui est à la mode, une autre fois on te dira que Amarok ou Clementine n'est pas installé donc qu'il faut jeter le bain avec le bébé. Texte tellement partisan que l'objectivité fini aux chiottes.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Distrowatch review

        Posté par Crao le 03 mars 2022 à 23:06. Évalué à 2.

        

        VLC ça ne fait que 20 ans que c'est à la mode, d'ici 20 ans ce sera passé ;)

        • [^] # Re: Distrowatch review

          Posté par Gil Cot ✔ (site web personnel, Mastodon) le 03 mars 2022 à 23:20. Évalué à 3.

          

          (: Autant que l'excellent MPlayer

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

• # gestionnaire slpkg ?

  Posté par benj13 le 05 mars 2022 à 15:16. Évalué à 1.

  

  Avis aux utilisateurs de Slakware…L'utilisation du gestionnaire de paquets "slpkg" est-elle une bonne idée selon vous ?

  • [^] # Re: gestionnaire slpkg ?

    Posté par Gil Cot ✔ (site web personnel, Mastodon) le 05 mars 2022 à 15:52. Évalué à 2.

    

    Bah si ça existe, c'est que ça répond à un besoin. Faut surtout voir

    • ce que cela apporte vraiment de plus
    • et au détriment de quoi cela se fait
    • puis si ça tient la route sur le long terme

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: gestionnaire slpkg ?

      Posté par benj13 le 05 mars 2022 à 16:30. Évalué à 1.

      

      Simple curiosité ! Visiblement les utilisateurs Slackware s'en tiennent au gestionnaire d'origine.

      • [^] # Re: gestionnaire slpkg ?

        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 05 mars 2022 à 18:09. Évalué à 2.

        

        Moi oui :-) Et mes besoins sont simples (je ne rencontre pas de Slackware en entreprise où je travaille sur d'autres distros.) Je ne me prononce pas pour les autres, mais suis curieux aussi (d'où mes deux premiers points.) :-)

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: gestionnaire slpkg ?

          Posté par benj13 le 05 mars 2022 à 18:32. Évalué à 1.

          

          Avec l'avènement de Slackware 15 je m'essaie "gentiment" à cette distribution. Le fait quelle soit la doyenne et vos commentaires ont aiguisé ma curiosité. Étant donné que d'origine, le gestionnaire de paquets ne permet pas la résolution automatique des dépendances. Venant de distributions où cette fonctionnalité est de mise, je souhaitais avoir votre avis éclairé sur la question.

          • [^] # Re: gestionnaire slpkg ?

            Posté par Yth (Mastodon) le 14 mars 2022 à 08:39. Évalué à 5.

            

            Mon avis sur la question des résolutions de dépendances est que je ne m'embête plus trop :
            J'installe une Slackware complète - éventuellement sans les catégories kde ou xfce, voire xap et x pour un serveur - et hop, la résolution de dépendances est terminée : ça fonctionne.
            Pour gérer le multilib (sur les machines où ça sert, en général c'est pour jouer), c'est le dépôt d'AlienBob, ajouté à slackpkg grâce à slackpkg+.

            Ensuite pour les slackbuilds, je n'utilise pas de dépôt tiers comme Slacky ou AlienBob (sauf son excellent ungoogled-chromium pour les trois fois dans l'année où j'ai besoin d'un chrome-like), mais je compile moi-même, avec un outil comme sbopkg, pour gérer la file d'attente de construction, et les dépendances.

            Cela dit slpkg est créé par un contributeur très actif du projet slackbuilds.org, et fait partie des divers outils recommandés pour gérer sa Slackware si on ne se contente pas de slackpkg.

            • Yth.

            Glossaire :
            pkgtools : le gestionnaire de paquets bas-niveau de Slackware, celui qui permet d'installer, mettre à jour, supprimer, et lister les paquets Slackware.
            slackpkg : gestionnaire de mise à jour automatique, qui va chercher les infos du dépôt Slackware sur internet, te liste les nouveaux paquets, les mises à jour etc, et permet de tout mettre à jour en une seule commande.
            Slackbuilds : un fichier .SlackBuild est un script permettant à partir des sources d'un paquet de compiler et générer un paquet Slackware. Le projet slackbuilds.org maintient près de 8000 slackbuilds pour étendre sa Slackware dans tous les sens. La Slackware elle-même crée ses paquets à partir de SlackBuilds gérés par l'équipe. Slackbuilds.org part du principe que tu as une installation complète et à jour d'une Slackware stable : là-dessus tout le dépôt s'installe, et la gestion de dépendance ne prend pas en compte les paquets considérés comme présent via Slackware.
            slackpkg+ : un plugin pour slackpkg permettant de gérer plusieurs dépôts de paquets, en plus du dépôt Slackware principal, comme par exemple multilib, alienbob, slacky, ou un répertoire personnel de slackbuilds produit soi-même, il permet aussi de lister les slackbuilds correspondant à une recherche par nom par exemple, mais sans gérer leur construction.
            sbopkg, sbotools : Outils permettant d'automatiser la construction de paquets Slackware (avec dépendances) à partir du projet slackbuilds.org.

            • [^] # Re: gestionnaire slpkg ?

              Posté par benj13 le 14 mars 2022 à 20:41. Évalué à 2.

              

              Merci pour ces éclaircissements ! C'est super sympa.

            • [^] # Re: gestionnaire slpkg ?

              Posté par HL le 16 mars 2022 à 17:27. Évalué à 3.

              

              J'ai essayé sbopkg, et je le trouve plutôt bien fait.

              Entre autres, il mémorise les options de construction des paquets (pratique par exemple si on veut Wine à la fois en 64 et 32 bits), il gère les dépendances en générant des files d'attentes (queues) depuis les info de dépendances récupérés des Slackbuilds.

              Si on a déjà utilisé les Slackbuilds avant (ce qui reste très simple), on sait ce que sbopkg fait on reste aux commandes de sa machine.

              A quoi ressemble sbotools ?

              • [^] # Re: gestionnaire slpkg ?

                Posté par Yth (Mastodon) le 17 mars 2022 à 18:39. Évalué à 3.

                

                Désolé, je ne sais pas, j'utilise depuis 15 ans un outil bash maison pas super user-friendly, mais que je fais évoluer selon mon bon plaisir.
                J'essaie de terminer la V3 en mode propre, en python parce que la maintenance des bonnes idées en bash est parfois cauchemardesque, et compatible avec certains formats de fichiers utilisés par d'autres outils d'admin slackware comme hoorex, mais ça n'avance pas vite…

                Bref, je n'utilise pas certains outils dont je vante les mérites ^{^}

                • Yth.

Suivre le flux des commentaires

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