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. -- David Griffith d...@661.org
