Re: pointless systemd dependencies
On Mon, 07 May 2018 22:56:36 -0400 The Wanderer said:
> I don't know of any single command - or even self-contained set of readily
> reusable commands - which would have identified the fact that installing the
> original package would have pulled in libpam-systemd, except for trying to
> install it.
I think a makeshift script can be put together to query the "rdepends" tree up
recursively. It might result in quite crowded list. This is the simple part of
it.
But then, having the full dependency genealogy tree, each forward dependency
(including non-systemd dependencies) would have to be analysed for its
relevancy (really needed or not). This is the difficult part.
E.g. in your example,
> [the original package] -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd
there are 4 relevancy tests to be done.
What I am trying to say is that, this needs to be solved at packaging level.
Or, IOW, distribution level. Packages should only "Depends" on absolutely
needed dependencies. All the others should be left to "Recommends" and
recommendations should not be treated as dependencies by default installation.
(APT::Install-Recommends "false")
I think that,
* Depending on probably or conditionally needed packages is the easy way.
* Treating recommendations as dependencies is the easy way again.
These could be solved by package installation scripts or a sophisticated
-possibly external- package management helper. This is a hard job to tackle
(working out actual dependencies correctly without going too chatty). Perhaps
apt needs to get a bit more sophisticated. This is a different topic.
When such knots are cascaded at packaging level (where it's relatively easier
to solve) undoing these knots at the user level is so inefficient that it is
almost equivalent to forking a new distro.
Regards
--
Abdullah Ramazanoğlu
Reply to: