What a Slackware derivative with dependency checking might look like
DISCLAIMER: This is not a serious suggestion. It's more of a jeu d'esprit, a philosophical exploration of how some limited degree of dependency checking might be introduced without damaging the essential structure of Slackware. The thing is certainly possible because Salix does it.
At present, the only newbie-friendly way to install Slackware is to do a full install, in which all dependencies are automatically satisfied. This is the recommended way to install and you will get little sympathy from the community if you get into trouble while trying something different. But inevitably it involves a big download, which is not practical for people with low-speed internet access or monthly download limits. Also there are people who have a temperamental dislike for anything that looks like bloat, even if it affects disk space only and not the size of the memory images of individual running programs.
The alternative way to install a distro is to start with a base system, like Debian's net-install, and add what you want. The result should be a system that contains only the software you actually need. This can be done with Slackware now if you are prepared to track down dependencies for yourself by using tools such as ldd to find errant libraries. But not everyone has the time to do that or wants to spend it in what most people would consider unnecessary work. So is it possible to automate the process without a centrally organised dependency system?
Clearly a dependency database of the kind that the Debian and Red Hat families use is off the cards. There is simply no way that could be compatible with the Slackware philosophy. It adds a whole raft of complications and makes the system much more fragile than it need be. Slackware aims for simplicity and robustness above all. It also tries to be as vanilla as possible, using packages defined by their developers, whereas a dependency database works best when packages are split up into different functions. Many Debian packages are only fragments of upstream ones, separated out to provide interfaces with other specific packages.
But there are other ways of organising dependencies. Crux for instance has no central dependency database. Instead the build script for each package includes a dependency list. The update manager uses this to download and install dependencies. Crux of course is source-based. The question is, "Could anything like this be done in a binary distribution?"
So here are some tentative requirements:
1: Package management must continue to be carried out with scripts, not programs. Programs depend on libraries and you can get trapped in a situation where the package manager itself becomes corrupt. That cannot happen with Slackware.
2: The slackbuild system must be preserved because it is brilliant.
3: The vanilla nature of Slackware must be preserved. Packages should not be splintered unnecessarily.
4: Nothing should be introduced which makes the system more complex.
5: Dependencies should be used only as a convenience to automatically install required packages. They should never become an excuse to remove packages without notice. That takes away the sysadmin's control over the system.
6: To avoid programs becoming inoperative because a necessary library has been removed, there needs to be a simple and robust method of checking reverse dependencies before uninstalling a package. However, the final decision must rest with the sysadmin.
I suggest adding an extra (optional) text file to the slackbuild, to be incorporated into the package. This would contain a list of essential dependencies, one per line. This file would be used by slackpkg to check for satisfied dependencies and to download and install the unsatisfied ones.The installpkg script would automatically append the file to the package description stored in /var/log/packages. It would then be very easy to determine the reverse dependencies of, say, a library by grepping for it in this directory.
This would not do what a centralised dependency database does. It would not for example allow variation in the software versions installed while maintaining overall consistency. But it would allow the degree of dependency management necessary to build up a system from a basic install without constantly needing to do one's own checking. And I think it would do this without threatening what is so distinctive about Slackware.
At present, the only newbie-friendly way to install Slackware is to do a full install, in which all dependencies are automatically satisfied. This is the recommended way to install and you will get little sympathy from the community if you get into trouble while trying something different. But inevitably it involves a big download, which is not practical for people with low-speed internet access or monthly download limits. Also there are people who have a temperamental dislike for anything that looks like bloat, even if it affects disk space only and not the size of the memory images of individual running programs.
The alternative way to install a distro is to start with a base system, like Debian's net-install, and add what you want. The result should be a system that contains only the software you actually need. This can be done with Slackware now if you are prepared to track down dependencies for yourself by using tools such as ldd to find errant libraries. But not everyone has the time to do that or wants to spend it in what most people would consider unnecessary work. So is it possible to automate the process without a centrally organised dependency system?
Clearly a dependency database of the kind that the Debian and Red Hat families use is off the cards. There is simply no way that could be compatible with the Slackware philosophy. It adds a whole raft of complications and makes the system much more fragile than it need be. Slackware aims for simplicity and robustness above all. It also tries to be as vanilla as possible, using packages defined by their developers, whereas a dependency database works best when packages are split up into different functions. Many Debian packages are only fragments of upstream ones, separated out to provide interfaces with other specific packages.
But there are other ways of organising dependencies. Crux for instance has no central dependency database. Instead the build script for each package includes a dependency list. The update manager uses this to download and install dependencies. Crux of course is source-based. The question is, "Could anything like this be done in a binary distribution?"
So here are some tentative requirements:
1: Package management must continue to be carried out with scripts, not programs. Programs depend on libraries and you can get trapped in a situation where the package manager itself becomes corrupt. That cannot happen with Slackware.
2: The slackbuild system must be preserved because it is brilliant.
3: The vanilla nature of Slackware must be preserved. Packages should not be splintered unnecessarily.
4: Nothing should be introduced which makes the system more complex.
5: Dependencies should be used only as a convenience to automatically install required packages. They should never become an excuse to remove packages without notice. That takes away the sysadmin's control over the system.
6: To avoid programs becoming inoperative because a necessary library has been removed, there needs to be a simple and robust method of checking reverse dependencies before uninstalling a package. However, the final decision must rest with the sysadmin.
I suggest adding an extra (optional) text file to the slackbuild, to be incorporated into the package. This would contain a list of essential dependencies, one per line. This file would be used by slackpkg to check for satisfied dependencies and to download and install the unsatisfied ones.The installpkg script would automatically append the file to the package description stored in /var/log/packages. It would then be very easy to determine the reverse dependencies of, say, a library by grepping for it in this directory.
This would not do what a centralised dependency database does. It would not for example allow variation in the software versions installed while maintaining overall consistency. But it would allow the degree of dependency management necessary to build up a system from a basic install without constantly needing to do one's own checking. And I think it would do this without threatening what is so distinctive about Slackware.
Total Comments 0
