Ça ne mettra sûrement pas à jour toutes les bibliothèques, non...
Ça ne mettra pas à jour la bonne quarantaine de bibliothèques partagées fournies par le paquet aaa_elflibs (qui se trouve dans a/), ni les bibliothèques partagées de la glibc et d’OpenSSL (paquets glibc-solibs et openssl-solibs, qui se trouvent dans a/).
Ça ne mettra pas à jour toutes les bibliothèques qui, parce qu’elle font partie d’un projet plus large, sont inclues dans un paquet situé ailleurs que dans l/.1 Par exemple et pour n’en citer que quelques-unes : libcryptsetup (dans a/cryptsetup), libFLAC (dans ap/flac), libmysqld (dans ap/mariadb)...
Ça ne mettra pas à jour non plus certaines bibliothèques qui ont pourtant leur propre archive source indépendante, mais qui pour diverses raisons ont été classées ailleurs que dans l/. Par exemple gpgme, libgpg-error ou encore cyrus-sasl, qui se trouvent toutes dans n/.
Ça ne mettra pas à jour la quasi-totalité des bibliothèques de X.org, qui se trouvent pour la plupart dans x/.
Ça ne mettra pas à jour la quasi-totalité des bibliothèques de KDE, qui se trouvent pour la plupart dans kde/.
J’aime beaucoup Slackware et je n’utiliserai une autre distribution pour rien au monde, mais sur ce point-là il faut regarder la réalité en face : la répartition des paquets en « séries » est purement un héritage de l’époque des disquettes. On fait très bien avec et il n’y a pas de quoi s’en plaindre, mais prétendre y trouver des avantages, c’est pousser le bouchon un peu loin à mon avis.
1 Rappel : Slackware ne décompose pas les projets upstream en multiples paquets. Sous Slackware, à de rares exceptions près, une archive source upstream = un paquet Slackware. Contrairement à Debian par exemple, où à partir d’une seule archive source foo-X.Y.Z.tar.gz on génère des paquets foo-bin pour le programme foo proprement dit, foo-libs pour les bibliothèques, foo-dev pour les fichiers d’en-tête, foo-doc pour la documentation, etc.
[^] # Re: Les séries
Posté par gouttegd . En réponse au journal Slackware a un quart de siècle !. Évalué à 5.
Ça ne mettra sûrement pas à jour toutes les bibliothèques, non...
Ça ne mettra pas à jour la bonne quarantaine de bibliothèques partagées fournies par le paquet
aaa_elflibs(qui se trouve dansa/), ni les bibliothèques partagées de la glibc et d’OpenSSL (paquetsglibc-solibsetopenssl-solibs, qui se trouvent dansa/).Ça ne mettra pas à jour toutes les bibliothèques qui, parce qu’elle font partie d’un projet plus large, sont inclues dans un paquet situé ailleurs que dans
l/.1 Par exemple et pour n’en citer que quelques-unes :libcryptsetup(dansa/cryptsetup),libFLAC(dansap/flac),libmysqld(dansap/mariadb)...Ça ne mettra pas à jour non plus certaines bibliothèques qui ont pourtant leur propre archive source indépendante, mais qui pour diverses raisons ont été classées ailleurs que dans
l/. Par exemplegpgme,libgpg-errorou encorecyrus-sasl, qui se trouvent toutes dansn/.Ça ne mettra pas à jour la quasi-totalité des bibliothèques de X.org, qui se trouvent pour la plupart dans
x/.Ça ne mettra pas à jour la quasi-totalité des bibliothèques de KDE, qui se trouvent pour la plupart dans
kde/.J’aime beaucoup Slackware et je n’utiliserai une autre distribution pour rien au monde, mais sur ce point-là il faut regarder la réalité en face : la répartition des paquets en « séries » est purement un héritage de l’époque des disquettes. On fait très bien avec et il n’y a pas de quoi s’en plaindre, mais prétendre y trouver des avantages, c’est pousser le bouchon un peu loin à mon avis.
1 Rappel : Slackware ne décompose pas les projets upstream en multiples paquets. Sous Slackware, à de rares exceptions près, une archive source upstream = un paquet Slackware. Contrairement à Debian par exemple, où à partir d’une seule archive source foo-X.Y.Z.tar.gz on génère des paquets foo-bin pour le programme foo proprement dit, foo-libs pour les bibliothèques, foo-dev pour les fichiers d’en-tête, foo-doc pour la documentation, etc.