On Mon 07 May 2018 at 05:50:27 -0700, David Griffith wrote: > On May 7, 2018 4:39:22 AM PDT, The Wanderer <wande...@fastmail.fm> wrote: > >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 > > I found someone who has already done most if not all of this analysis > and has set up a repo containing non-systemd-using packages. Perhaps > this can be used as a foundation for something official.
Someone might be motivated if they could find what you are referring to. -- Brian.