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
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.
[^] # 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é à 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).
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©®TM 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.