Yeah well, please tell me what to do haha :)
I want to install a snap app but snapd from AUR depends on libsystemd. Ouch!
Actually I usually install Spotify on my machines but that wants to pull libsystemd as well. Ouch!

Although the name is frightening now (hahaha...) I don't see how it could negatively affect obarun since it won't be used by the system in any way, would it?
Is it safe to install libsystemd as a program dependency?
When I use trizen to install such packages it actually warns that libsystemd is on the ignore list.
When I use pacopts it would just install right away without any warning.

What should I do?! Avoid such packages completely?
You cannot install libsystem:D, you will go on trouble with udev library. You need to avoid such packages. Take the pkgbuild from snap and spotify and rebuild it without the support of system:D libsystem:D.
Obarun is free of system:D, if you want to use it you need to switch to another build concept :)
Woah nah, that's definitely way too much work for me. There's a limit I'm willing to spend time on these kind of things :D
Plenty of alternatives around ;)
Thanks for making it clear.
I would appreciate pacopts to warn about this though. It actually seems to ignore the ignore list hahaha.
Something along the lines:
"Though shalt not install this package for evil is about to corrupt your soul!" hahahaha ;)
23 days later
In an experimental installation where I converted bluestar-plasma into obarun there was a pkg called gnome-disk-utility which now requires libsystemd. It is gnome so it is expected and who knows why it all of a sudden it needs libsystemd, but I am just reporting it. I couldn't really care less about it, but I see the same edition on void where there is no libsystemd.

  • [deleted]

  • Post #6
Hello marianarlt

Spotify is built with systemd deps ? Are Spotify code source available ?
2 months later
@ jean-michel 
marian@ s6 [1] ~ % pikaur -S spotify
Reading repository package databases...
Reading local package database...
Resolving AUR dependencies...

:: New dependencies will be installed from repository:
 libcurl-compat (for spotify)                               -> 7.62.0-1
 libcurl-gnutls (for spotify)                               -> 7.62.0-1
 libsystemd (for spotify)                                   -> 239.303-1

:: AUR package will be installed:
 spotify                                                    -> 1.0.92.390-1

:: Proceed with installation? [Y/n] 
:: [v]iew package details   [m]anually select packages
in the case of spotify the systemd dependency is for the udev component(covered by eudev)
i notice eudev packbuilds(eg. eudev-git) in the AUR have this line: 
replaces=('eudev' 'udev' 'systemd' 'libsystemd' 'systemd-tools' 'libgudev')
which, i guess, alows spotify to build without pulling systemd when eudev is installed..
compared to eric's eudev: 
replaces=('eudev-obarun' 'udev')
the easiest solution is to edit the spotify pkgbuild line: replacing libsystemd with eudev 
depends=("alsa-lib>=1.0.14" "gconf" "gtk2" "glib2" "nss" "eudev" "libxtst" "libx11" "libxss" "openssl-1.0" "desktop-file-utils" "rtmpdump")

looking at the SlackBuild for gnome-disk-utility:
configure arg: 
  --disable-libsystemd-login
and from void template (meson build) 
configure_args="-Dlibsystemd=false"
Funny, I applied this trickery and it did indeed install, but it won't actually work. Spotify seems to have some real dependency here. The screen would just stay black, not signals of program initialization whatsoever.
Thanks for pointing this out though!
even funnier ;) , i just installed it (and got a free spotify account) and it appears to working for me no problems..
just to be sure, i removed systemd-dummy (which i don't need for anything else anyways) and it still works..
Oh now that's interesting. Thanks for the test run from your side. Maybe I'll play around with this a bit then.
2 months later
I also installed it and working fine for me as well
11 days later
# 9 is out of date. Works fine for me as well now. Thumbs up!
18 days later
Today friday, march 15th I wanted to do a routine $ sudo pacman -Syyu when something unexpected happened. I think I have read this before but it must have been long ago and forgot about it. I am using KDE Plasma for my desktop, I really defend this software suite despite of its bloat; but today pacman wanted to upgrade rtkit, which is a dependency for the Plasma audio applet including pulseaudio. Now the issue with this is that rtkit has a dependency on systemd...and I can't remove rtkit because it would break the whole Plasma-meta package in the end of the chain...David Edmundson writes in a blog post from 2015 about KDE Plasma and systemd and what the components interesting to the KDE team are. I didn't expect this...I din't know this...
I can skip the update for rtkit, but it'll result in a partial upgrade. I suppose it'll leave me prone to errors. Oh my...
Also another funny find I did today was this:
# pikaur -Ss somepackage
:: error: pikaur requires systemd >= 235 (dynamic users) to be run as root.
You are trying to replace obarun's rtkit by arch rtkit, that is why.
Obarun's rtkit, is a bit outdated, but has no dependency on libsystemd.
It seems as Erik has pulled it from the repository, it was there yesterday.
Interesting and good to know. But looks like you're right, doesn't appear in obarun: 
marian@ s6 ~ % sudo pacman -Ss rtkit
extra/rtkit 0.12-1 [installed: 0.11+10+g493a135-2]
    Realtime Policy and Watchdog Daemon
Thanks for the quick pointer as always!
rtkit was removed from Obarun repo because the last version is impossible to build without libsystem:D, so rtkit bye bye, again dev prefer leave portability for system:D.
Anyway the only depends for rtkit on plasma comes with pulseaudio, the Obarun pulseaudio package was rebuild to remove rtkit dependency for it.
You have an another version of pulseaudio on testing purpose here : https://framagit.org/obarun-pkgbuild-testing/pulseaudio-light.
The binary package for this one can be obtain appending your pacman.conf with : 
[jm-testing-repo]
SigLevel = Required
Server = https://repo.obarun.org/jean-michel/testing-repo

  • [deleted]

  • Post #18
Hello

Pipewire pkgbuild has been rewritten without rtkit deps and added to obarun pkgbuild list.
Package binary is available on my testing repo.

Note for 66 init/supervisor users, be careful. My repo contains a testing version of 66-tools/66 services and could break you system at next reboot.

Update pulseaudio and pipewire like that:
pacman -Sy jm-testing-repo/pulseaudio jm-testing-repo/pipewire

My pulseaudio light disable list:

--disable-asyncns --disable-avahi --disable-bluez4 --disable-bluez5 --disable-default-build-tests --disable-esound
--disable-gconf --disable-gsettings --disable-gtk3 --disable-hal-compat --disable-ipv6 --disable-jack --disable-lirc
--disable-openssl --disable-oss-output --disable-oss-wrapper --disable-rpath --disable-samplerate --disable-systemd-daemon
--disable-systemd-journal --disable-systemd-login --disable-tcpwrap --disable-waveout.

If you are interested about the purpose of each of these option,
download pulseaudio source https://freedesktop.org/software/pulseaudio/releases/pulseaudio-12.2.tar.xz
extract the archive
cd to the pulseaudio folder
and execute ./configure --help
Don't take all of it as 100% correct, it is as far as I can understand.

On arch current rtkit is 0.12-1, on artix it has remained at 0.11+11
The artix package doesn't have a direct dependency on systemd, just dbus and polkit.
You can fool the pkg to be installed as its dependency is satisfied by obarun's polkit, but I think eventually it will create some errors. Artix's polkit has a dependency on libelogind (which now incorporates lib-systemd functionality, lib-systemd-dummy will be removed).
I don't know whether 0.12 has differences in such dependencies and whether artix will update it soon, I'll keep an eye on it.

What I don't understand is that running about the same stuff on obarun and artix, I can live in obarun without consolekit but I don't think I can survive in artix without lib/elogind, which is supposedly the other option. Elogind is a direct chunk of systemd, it evolves in parallel. Consolekit2 has its own independent path.

I don't judge good/bad or good/better either way, it appears to me to be different paths in dealing with the same monsters. Some of the differences between devuan/antix are based on the same dilemmas, consolekit/elogind, it is just that they are dealing with a more vicious monster (debian) than the cute little monster arch is.

By comparison the independent path of Void seems a less stressful one: 
[-] dbus-elogind-1.12.12_1      Message bus system
[-] dbus-elogind-libs-1.12.12_1 Message bus system - shared libraries
[-] dbus-elogind-x11-1.12.12_1  Message bus system - X11 support
[-] elogind-241.1_2             Standalone logind fork
[-] elogind-devel-241.1_2       Standalone logind fork - development files
[-] libelogind-241.1_2          Standalone logind fork - elogind library
[-] polkit-elogind-0.115_3      Authorization Toolkit
[-] ConsoleKit2-1.2.1_2       A framework for defining and tracking users, login sessions, and seats
[-] ConsoleKit2-devel-1.2.1_2 A framework for defining and tracking users, login sessions, and seats -...
[-] rtkit-0.11_16 Realtime Policy and Watchdog Daemon
Their rtkit has been stuck on 0.11 as well. So there may be a rtkit fork coming out soon, who knows.
I can live in obarun without consolekit but I don't think I can survive in artix without lib/elogind

depends of your needs, if you try pactree -r consolekit you will see that no packages depends on it. try to do an pactree -r elogind command on Artix and i think you will see a different behaviour of dependencies handling

Powered by Obarun