On 2018-05-06 at 21:47, David Griffith wrote: > Could we start the process of identifying packages that have > dependencies on systemd in some way that is are not actually > required?
This is a seriously nontrivial task. As I understand matters, the only sure way to do it would be something like: 1. Start with a systemd-free computer. 2. Attempt to install a package. 3. See whether it tries to install systemd, either by direct dependency or by an indirect cascade of dependencies. 4. If it tries to install systemd by direct dependency, analyze the source and functionality of the package, to determine whether or not there would be a way to get it to do what it needs to do without referencing systemd in a way which would require the dependency. 5. If it tries to install systemd by indirect dependency, identify the package in the dependency chain which results in pulling in systemd, and then either: 5a. Analyze that package in the same way as under step 4. 5b. Analyze the package above that one in the dependency chain to determine whether or not it can be made to do what it needs to do without referencing that package in a way which would require the dependency. 5.b.1. If not, repeat step 5b for the next package up the chain, and keep repeating for as many packages are in the chain. 6. Repeat from step 2 with another package, until every package has been checked. And all of that is just to identify the packages in question. Modifying them to remove the dependencies would be another nontrivial task in many cases; getting the package maintainer to accept patches which do so would be still another nontrivial task. I did notice when one package which I run on my primary (systemd-free) computer developed an indirect dependency on libpam-systemd (as part of fixing an arguably minor bug in a feature I don't use), reported that as a possible unintended result to the maintainer (asking whether there was any possibility of a way forward which wouldn't require me to build that package locally going forward in order to avoid systemd), and was fortunate enough that the maintainer found an alternative dependency which would avoid the indirect chain to libpam-systemd. But that was something I noticed in the course of checking a routine dist-upgrade, not the result of embarking on a project to analyze the archive in search of such packages - and even then, I was lucky that A: an alternative solution could be found and B: the maintainer was sufficiently non-unsympathetic to the desire to avoid systemd to be willing to look for and implement one. All of which is to say: I am not at all certain that this project would be at all worth the time and effort it would require. But I am not one to tell others not to do work they think is beneficial. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature