What are the different “types” of dependencies?

[Member stevesr0]

I am trying to understand the different “types” of dependencies.

Why?

Because this distro is dedicated to running without systemd. And many packages that one might wish to use “say” they are dependent upon systemd.

In reading a bit, I have come to understand that there are several types of “dependencies”. However, as a noobie, I don’t know whether this is (a) correct and (b) useful distinctions to make.
(I am hoping to use this “insight” to help me make my Pipewire install work without elogind or libelogind0.)

(1) “False” dependencies.
It has been pointed out in this forum that some “dependencies” are not really needed. For these “false” dependencies, creation of an empty “dummy” package named for the dependency program, allows a desired application to be installed and run.

I believing that there are at least two other “types” of dependencies:

(1) “Start/stop” dependencies.
The program is dependent upon a another program only for it’s launching and stopping. Systemd takes on this responsibility. In distros without systemd, other programs can do this.
er
(2) “Functional” dependencies.
The program depends upon functions provided by other programs. Fixing this is likely to require rather high level computer skills.

Appreciate comments about this categorization and its possible usefulness.

stevesr0

[Member PenguinGuy]

Helpful

Up

0

::

I haven’t noticed any issues other than you can’t run old qt programs that need it for the UI.

[Member Robin]

Helpful

Up

1

::

This is a really good question. Unfortunately the answer is way more complex you might think.

Firstly, the obvious: Yes, dependencies are functional different, depending on which actual function a package has which was declared as dependency for another package. This function (and in consequence also the category you’d put it into) can be different for different software for which the dependency to another package was declared.

The dependencies for a package are declared in a config file within the .deb package, and the Package Maintainer (who is not the programmer of the software in most cases) makes these decisions. So it is quite common, some dependencies are declared which actually are not really needed for running the software. Only the maintainer THOUGHT erroneously they are needed. From this comes what you call “false” dependencies. Also the opposite case is possible: The maintainer wasn’t aware that on a specific version of an OS a specific package the software really needs isn’t present (e.g. since it’s about a very common package installed usually on most systems, but not as an OS default). Then you will run into the “missing dependency” issue when trying to install. To avoid this situation I believe some maintainers rather add dependencies which are not really needed or are fulfilled in some other way on some systems, simply since they believe to be on the safe side this way. In some rare cases some maintainer (or a distro) wants to promote a specific technique like e.g. systemd, so all their packages contain dependencies to this, even when not really needed. This could be called abuse of the dependency system, but don’t let’s discuss these business policies here, let’s talk about the technical aspects only.

Basically dependencies were invented to avoid duplicate install of multiple instances of identical code on a device: All Software uses default libraries or other pieces of software it needs to function, and the package maintainer only declares what he thinks what is needed. This concept saves much storagespace on disk and also on execution in RAM: A package many other packages depend on needs only to be installed once, and can be updated independently of all the programs depending on it if a bug was found later. So this concept is not a bad idea basically. But… it creates on the other hand what people commonly call Dependency Hell.
In this wikipedia lemma you’ll find some more “types” of categorised dependencies. And this hell is not Linux specific, in Windows it is called DLL Hell and results exactly from the same concept.
Theoretically the programmer of a software could avoid this hell by linking his code statically against a specific version of a dependency while compiling, so the code is included in his executable, and file all dependencies needed along with his code in his source repository. But this concept has way more drawbacks than the nowadays commonly used dynamic linking of dependencies, even when the latter causes the dependency hell we sometimes face.

The easy cases (or you might call it categories) you have described already. Way more difficult are the version conflicts. E.g. if a package was called in antiX 19 (debian buster based) “libvpx5” and you update your system to antiX 21, you won’t find this package anymore, even when the precise code still exists: Now it is called “libvpx6” and is installed by default already. Only all packages which were not actively maintained anymore (so no maintainer fixed the changed naming inside their config files) will cease installing.

And now: You might get away by simply creating a dummy package for the missing one, and the software might even work, since the functionality is actually present in your system, installed by the successor package already. But as well this might fail. It’s like a lottery game, in some cases you might get the jackpot, and on most cases you’ll draw a blank. You can never tell in which of your dependency-categories a package goes: for one software the replacement by dummy might work, another software tolerates it (providing some limited functionality then), and again other software refuses even to start.

This is not enough, even packages with the same name ship in different versions, which are also declared in the config file of the .deb package. And also here the maintainer can hard code a specific version of a dependency package, or a minimum version, but as well a maximum version or a version range. And again, in many cases other versions would also work fine, but the maintainer wasn’t aware of this. So you will never know before you try installing, whether a package installs properly on your system and works out of the box, or whether you can trick it into installing in some way, and whether the software will work fine then.

So yes, this is actually a dependency hell, and you need mostly the skills of a true programmer to resolve it properly if you ran into issues when you force install a package not actively maintained by the distro.

And this is where my knowledge about this matter ends, some other people might step in and supplement what I have neglected.

Windows is like a submarine. Open a window and serious problems will start.

[Member ModdIt]

Helpful

Up

0

::

@steves, did you dig around for ideas over at artix. Looks like your quest is not impossible.

pipewire (reminds me of pipedream) is very closely intwined with system.d read
over at IBM/red hat and note they are also wanting to further the troubles with own package format, rpm
presumably was too free for the ambition to lead package formats and development.
Usual trash, us companys wanting to own controll, spy on and monetize all others.

`https://www.reddit.com/r/artixlinux/comments/qqgvzc/wireplumber_the_new_pipewire_session_manager/
https://pipewire.pages.freedesktop.org/wireplumber/running-wireplumber-daemon.html#replacing-pipewire-media-session´

• This reply was modified 8 months, 2 weeks ago by ModdIt.
• This reply was modified 8 months, 2 weeks ago by ModdIt.

[Member iznit]

Helpful

Up

1

::

This is post #1 of 3 total I expect to type today. #1 is for “just the basic details”.

An end user is not expected to know about or care about all the details in robin’s post and in this post. The goal of package management is to hide [[[most of]]] the complexities surrounding “dependencies”.

The tools, the rationale, the methodology of Debian package management are well documented.
Here’s the page [[[aka chapter]]] that addresses your question(s) https://www.debian.org/doc/debian-policy/ch-relationships.html

That “Declaring relationships between packages” page explains some “types of [quasi]dependencies” not mentioned in robin’s post and not often mentioned in discussions. An end user will benefit from understanding the differences [[[nuances]]] between “Depends” vs… “Recommends”, or “Suggests, or “Enhances”. Also, you will benefit from at least recognizing that these additional qualifiers exist: Pre-depends, Breaks, Conflicts, Provides, Replaces.

The antiX policy configuration is preset to NOT automatically install ancillary packages which a package maintainer has flagged as “Recommends”, or “Suggests, or “Enhances”. As a result, you will occasionally discover that a packaged program installs without error but certain features or functions within the program are inoperable. The output of this command will show any “Recommends”, or “Suggests, or “Enhances” items…..

apt-cache show <package_name>
…..and before crying “a bug!” about any non-working features of the program, you should probably install the listed “Recommends” packages and retry, checking if the “broken” features now work correctly.

[Member iznit]

Helpful

Up

1

::

Blame politics or whatever, but any program packaged by and for Debian that requires start//stop via service supervision probably [[[either directly or indirectly]]] depends on systemd. The package control file can [[[and ideally would]]] specify <systemd or alternative1 or alternative2…> yet the maintainer for any particular package probably lacks the time or ability to install//test against “alternative1” et al.

I am trying to understand the different “types” of dependencies.

“Pre-depends” exists among the available flags, but I struggle trying to fit systemd dependence as a “type”. The core of the Debian distribution is comprised of approx 200 “required” [[[aka essential https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities]]] packages. Among these, probably a few [[[3?]]] are packages which provide various systemd libraries. No need to trust “probably”. You can use the “dpkg-query” command or “apt list” command to generate an exact list https://unix.stackexchange.com/questions/73242/finding-all-essential-packages-with-apt

I don’t hve bookmarked link to a definitive doc but as I remember it, Debian policy discourages [[[prohibits?]]]] maintainers from listing “required” packages among the “Depends” or “Pre-Depends” or otherwise flagged packages within the control file of any particular package.

Some of the various systemd libraries and supporting bits are provided on Debian systems via numerous separate packages which are designated as “important” or “standard” or “optional” [[[vs “required”]]]. This approach benefits modularity, but also invites confusion. “I can’t understand why does <package_name> depend on libsystemd0, libpam-systemd…..” The reason why in many cases is probably confusing because it involves an indirect [[[aka “chained”]]] dependency.

[Member iznit]

Helpful

Up

1

::

The “apt-rdepends” command [[[has a manpage]]] recursively lists the dependent packages for a particular package.

The utility command “ldd” [[[has a manpage]]] prints a list of the shared libraries required by a particular program.

The “strace” command [[[has a manpage]]] can generate a list of all files accessed by a running program.

If you “sudo apt install apt-file” you can use the apt-file command [[has a manpage]]] to search for files within Debian packages, even packages not currently installed locally on your system.

A package maintainer may need to rely on those utilities to calculate the “Build-depends” and “Depends” for a particular package. We too can use them toward “understanding” non-obvious chained dependencies.

[Member stevesr0]

Helpful

Up

0

::

Hi all,

Wow. Thanks for the wonderful responses and references. I have been looking at various Debian documents on packaging and dependencies, but the comments here have all expanded my sense of the issues.

Hi moddit,

re: pipewire.

I have found discussions of changing Pipewire’s packaging to eliminate the systemd dependency at Artix, Void, Gentoo, Devuan and Slackware. They have different approaches to managing the functions that systemd was providing. So I am not sure how their solutions would apply to antiX – and especially since I am not clear which eliminate elogind and libelogind0 and which ones still utilize them.

At the moment, I am trying to understand this by asking the folks who state they have a successful approach for more details. I will then try repeat what they did, in the same distro.

If I get something working in antiX, I will post it <g>.

stevesr0

[Member iznit]

Helpful

Up

0

::

“discussions of changing Pipewire’s packaging to eliminate the systemd dependency at…..”

Great if you can post links here to any of those discussions. We might all learn from seeing different ways to accomplish the elimination, even if not directly applicable in antiX. For pipewire and other programs intended to be started as a “service”, I guess the package pre-install or post-install script needs to detect which service manager is present in use on the antiX system [[[sysV, or runit]]] and copy an appropriate init script [[[instead of a systemd “.service” file]]] into place. Plus, for sysV, call update-rc.d

[Member ModdIt]

Helpful

Up

0

::

agree with iznit the more we look at a problem from different angles the more we may
see simple solutions. Long back on arch a post without useful communication would have
not been well received. er got the poster rightfully flamed.

Regarding working on debs to rid them of unnecessary depends it seems to me better to
work as root. I am still trying to figure out some of the fine points.

Maybe some pointers from the maximo, anticapitalista could help, if he can spare the time that
is. We all appreciate he is often busy and enjoy the results with regard to antix pretty much
daily.

[Member stevesr0]

Helpful

Up

1

::

Hi iznit and moddit,

I am listing below the links to the pages I have found so far that give ways to use Pipewire on nosystemd distros:

*(1) Devuan: https://blog.uvokchee.de/2022/04/backporting-pipewire-in-devuan.html This actually described the steps to get the most recent version of Pipewire runnning without systemd by first modifying the source and then using the meson build provided by the Pipewire project. (a Devuan forum post describes another approach: https://dev1galaxy.org/viewtopic.php?id=4608)

(2) Gentoo: https://wiki.gentoo.org/wiki/PipeWire#Login_without_session_management (especially Section 2.3.2 and 2.4)

(3) Artix: https://wiki.artixlinux.org/Site/PipewireInsteadPulseaudio (N.B. in addition, there are also forum posts on Artix describing individual experiences trying to install/run Pipewire: https://forum.artixlinux.org/index.php/topic,4202.0.html)

(4) Void: Two pages from the Void Linux handbook: https://docs.voidlinux.org/config/media/pipewire.html and https://docs.voidlinux.org/config/session-management.html (deals a bit with choices including elogind and seatd)

In addition, I looked a bit at Debian’s information on packaging for developers (not package management for users). There is a main page with links to specific topics: https://wiki.debian.org/Packaging.

I have looked at the Pipewire site (Pipewire.org) and read statements that Pipewire can run without systemd, but I haven’t seen any detailed discussion of what is done instead.

I don’t know whether any of these approaches will work with only minor adjustments in antiX – or at all. My plan is to try out some of these distros and see whether I can successfully imitate a systemd free Pipewire install on any of them. In my clumsy hands, that will likely take a significant amount of trial, error and time.

If any of the more skilled forum folks find these to be directly transferable to antiX, that would be great.

stevesr0

P.S. This thread is about dependencies; Pipewire is just a reasonable example to talk about the complexities of dependencies.

[Member stevesr0]

Helpful

Up

0

::

Additional comment re: Pipewire without systemd (or dbus).

From the Pipewire Wiki updated by the head developer (Wim Taymans) (https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#does-pipewire-require-dbussystemdflatpak),

Does PipeWire require DBus/SystemD/Flatpak
No, all of these are optional dependencies, PipeWire can function without those dependencies.

DBus can be disabled at compile time or at runtime. If enabled, it is used for:

*Bluetooth support. The bluetooth stack (Bluez) on Linux is provided using a DBus API. Without
DBus, there is no bluetooth support possible.
*Interface with RTKit to acquire realtime priorities. If no DBus is available, it will fall
back to posix scheduling API, which requires the user to have the right limits.
*Tag clients that are managed by the portal with the right properties so that the session
manager can securely handle them.
*Let the session manager perform Device reservation. This can be used to improve interoperation between JACK and PipeWire so that they can manage exclusive device access between each other.
*Register the pulseaudio server name on DBus. This might be used by some clients to detect
when a pulseaudio server is running.

Systemd integration can be disabled at compile time. If enabled, it is used for:

*Logging to the journal. A fallback logger will use stderr instead.
*Management of the PipeWire, PipeWire-pulse and session manager services.
*Socket activation of the PipeWire and PipeWire-pulse services.
*logind to manage logged in users. This is mostly important for the Bluetooth services because only one user can use the bluetooth stack at a time.

So, according to the developer, Pipewire can work without systemd – if it is modified when compiled.

There is a github page from 2021 describing how to build Pipewire (https://github.com/pipewire-debian/pipewire-debian/wiki/Compiling); not sure if its instructions are “up to date”, but the April 2022 post from a Devuan user also described compiling a modified Pipewire using the meson build, so between the two a successful systemd free Pipewire might be obtainable.

I will report back after trying this approach out.

stevesr0

• This reply was modified 8 months, 2 weeks ago by stevesr0.
• This reply was modified 8 months, 2 weeks ago by stevesr0.

[Forum Admin anticapitalista]

Helpful

Up

1

::

I have finally managed to build systemd/libsystemd0 and elogind/libelogind0 free debs of pipewire and wireplunber debs.

64bit debs can be found here: https://download.tuxfamily.org/antix/debian/pool/dev/

I have no idea how well these will work or even if they work at all.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member stevesr0]

Helpful

Up

0

::

UPDATE: I just compared the packages with those installed on my Sid system. libwireplumber-0.4 and libwireplumber-0.4-dev are installed on my system BUT only the libwireplumber-0.4-dev package is present in the linked repository. Ignorant question: I assume that the .dev version contains everything in the “regular version”, so there is no need for the “regular” version if the .dev version is installed?

If that is the case, the repository contains every Pipewire related package that exists in my working Sid system.

———————————————
Hi anticapitalista,

WOW!! That’s amazing and terrific.

I look forward to trying it out.

Is it (potentially) compatible with any antiX version (Sid, antiX-21, antiX-19 or antiX-22)?

Does it matter if the system init is sysvinit or runit?

stevesr0

• This reply was modified 8 months, 2 weeks ago by stevesr0.
• This reply was modified 8 months, 2 weeks ago by stevesr0.

[Forum Admin anticapitalista]

Helpful

Up

1

::

Hi anticapitalista, …

Is it (potentially) compatible with any antiX version (Sid, antiX-21, antiX-19 or antiX-22)?

Does it matter if the system init is sysvinit or runit?

stevesr0

Only sid and possibly testing (for now).
It shouldn’t matter if sysVinit or runit is used.
You can be the tester 🙂

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Author]

Posts