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.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . En réponse à la dépêche Tout arrive, même Slackware 15.0. É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.