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.