Re: Slackware n’intègre pas de résolution de dépendances ?

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