Skip to main content ↑ ↓
Topic: "Replace systemd-dummy with system/elogind? [Y/n] n" (Read 1848 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

"Replace systemd-dummy with system/elogind? [Y/n] n"

Just went to do a update and saw that systemd-dummy was due to be replaced with elogind so I exited the uprade to try and see what was going on.

From a quick look I can see that
Code: [Select]
+    ln -sfv libelogind.so ${pkgdir}/usr/lib/libsystemd.so
+    ln -sfv libsystemd.so ${pkgdir}/usr/lib/libsystemd.so.0
+    ln -sfv libelogind.pc ${pkgdir}/usr/lib/pkgconfig/libsystemd.pc

has been added to the elogind PKGBUILD and these files do not match the names of those to removed when systemd-dummy is replaced.

I guess systemd itself has changed the location and names of the systemd libs ?

Anyway my slight issue is this:
I don't have elogind installed and don't want it. It caused major problems trying to get my computer to do exactly what I wanted. Which was start a second X on another tty under the same user. (At least I think that was what the issue was, my memory could be failing me but it pissed me off about something that much I know). 
Without elogind what I wanted to do worked easily. I've lost some functionality, mainly shutdown / restart from the desktop menu but I can live without that.  I did need to make my own PKGBUILD at the time which did nothing other than
Code: [Select]
provides=('elogind')
conflicts=('elogind')
to get round lots of dependency issues but, while a bit 'hackish', it worked for me.
Simply put I just don't want elogind and have been fine without it from just a few days after I installed Artix in Sept last year.

Can any devs give any more background on the reasons for the change and why the functionality of systemd-dummy has been bundled with elogind

At present I'm thinking I need to take your new elogind PKGBUILD and edit it to stop it installing anything other than the files I quoted above. But if there's anything else you can add please do.

Just curious.  Your distro. Do what you like with it. Thanks for all the hard work  :D


Edit:
I promise I did have a quick look before I posted but missed this.
Topic: Don't install systemd-dummy/systemd-libs-dummy in pkgconfig
which goes someway to explaining what is going on. I will have to test this new elogind and see if it still gets in my way.
I don't expect my niche case to be supported by your goodselves

Re: "Replace systemd-dummy with system/elogind? [Y/n] n"

Reply #1 –
Basically starting with elogind 241, the library is now a drop in replacement of libsystemd. That is anything that "required" (I say this loosely since things like chromium mysteriously have a systemd dependency) systemd can now be fully satisfied by elogind instead.

Just don't start the elogind service with openrc/runit. It shouldn't do anything if you just install the package for the libraries and not the openrc/runit scripts.

Re: "Replace systemd-dummy with system/elogind? [Y/n] n"

Reply #2 –
Quote from: Dudemanguy – on
Just don't start the elogind service with openrc/runit. It shouldn't do anything if you just install the package for the libraries and not the openrc/runit scripts.

Well the migration wiki states this
Quote
You almost certainly need to enable udev unless you know what you're doing; dbus and elogind are no longer required to be explicitly enabled, as they are started on demand.

So I'm not sure about that ?

Anyway I took the plunge and installed elogind. Rebooted and couldn't boot into Plasma (or openbox/KDE) but could just openbox
Quickly found out that /tmp/runtime-user was not being created which stopped Plasma and KDE from starting. Creating the dir (with proper ownership and permissions) allowed Plasma to start.

It didn't make a difference whether elogind was enabled as a service or not (and I tried both default and boot) the dir was not created. Altered my PKGBUILD to include a systemd 'provides' and built and installed it which removed elogind.
Code: [Select]
# This is an example PKGBUILD file. Use this as a start to creating your own,
# and remove these comments. For more information, see 'man PKGBUILD'.
# NOTE: Please fill out the license field for your package! If it is unknown,
# then please put 'unknown'.

# Maintainer: Your Name <[email protected]>
pkgname=myprovides
pkgver=1
pkgrel=3
arch=('x86_64')
license=('WTFPL')
provides=('elogind' 'systemd')
conflicts=('elogind')

package() {
	cd $scrdir
}

Everything worked again.

It is most likely something I have done in the past.

I will edit the new elogind PKGBUILD to just install the systemd libs and see what happens  :)

Re: "Replace systemd-dummy with system/elogind? [Y/n] n"

Reply #3 –
Just thinking out loud here.

It turns out I still had libelogind, and always have had. So I don't think I need to do anything else at this point.
libelogind contains everything to keep packages that depend on systemd  libs happy. Someone tell me if I'm wrong :)

Re: "Replace systemd-dummy with system/elogind? [Y/n] n"

Reply #4 –
Quote from: gripped – on
Well the migration wiki states this
So I'm not sure about that ?

Anyway I took the plunge and installed elogind. Rebooted and couldn't boot into Plasma (or openbox/KDE) but could just openbox
Quickly found out that /tmp/runtime-user was not being created which stopped Plasma and KDE from starting. Creating the dir (with proper ownership and permissions) allowed Plasma to start.

It didn't make a difference whether elogind was enabled as a service or not (and I tried both default and boot) the dir was not created. Altered my PKGBUILD to include a systemd 'provides' and built and installed it which removed elogind.

Oh perhaps you're right. I didn't think elogind did anything if you didn't start/use the service, but I'm thinking I was probably wrong there. It's very likely that various desktop environments will see that its installed and try to do something with it.

Quote from: gripped – on
Just thinking out loud here.

It turns out I still had libelogind, and always have had. So I don't think I need to do anything else at this point.
libelogind contains everything to keep packages that depend on systemd  libs happy. Someone tell me if I'm wrong :)

This should work though. I forgot libelogind can be installed by itself. Yeah that's probably the solution you want here. Just get the libs and forgot everything else.
 

Re: "Replace systemd-dummy with system/elogind? [Y/n] n"

Reply #5 –
Quote from: Dudemanguy – on
Oh perhaps you're right. I didn't think elogind did anything if you didn't start/use the service, but I'm thinking I was probably wrong there. It's very likely that various desktop environments will see that its installed and try to do something with it.

This should work though. I forgot libelogind can be installed by itself. Yeah that's probably the solution you want here. Just get the libs and forgot everything else.

MX/linux comes with the whole systemd installed, but it is not active and has nothing to do with init or service supervision.  It is all handled by what antix has developed, which blocks everything related to systemd.  The twins (MX/antix) seem like they are on the two extremes of debian without systemd.  Devuan fits somewhere in the middle like a gray color.    To be honest I have booted a live image of MX in a VM once out of curiosity, I know very little more about it.
AntiX-Sid is fine for me.  How do funky DEs use systemd functionality without its services running by it, I have no idea.  I am sure a more experienced admin can get ideas from MX.