Why are systemd files present in Devuan?

golinux · 2018-03-04 20:17:54

Why are there systemd files present in Devuan? That question has been asked and answered several times including recently on the DNG mail list at the end of this post. Sadly that link is now fubared:

I issued $locate systemd
and got 200 lines of output, including
/etc/systemd/system/* (23 files)
/lib/systemd/system/* (60 files)
/lib/x86_64-linux-gnu/libsystemd.so.0 (and 0.17.0)
/usr/lib/systemd (25 files)
/usr/bin/deb-systemd-helper ((and deb-systemd-invoke)
/var/lib/systemd/deb-systemd-helper-enabled/* (68 files)
/var/lib/dpkg/info/libsystemd):amd64* (5 files)
This seems a lot to me. Please could you confirm that an ascii
installation should contain 200 systemd files as part of a normal
ascii installation. Sorry to trouble you if these are trivial
questions, but they feel far from that.
Many thanks
leloft
Most of those "alarming" files are just systemd units files, put there
by daemons/packages/utilities who "also" support systemd in a way or
another. So they are not alarming but just *totally* *harmless* if you
don't have a running systemd as PID 1, since only systemd understands
and can run them. It would be *totally* *useless* (and utterly
*stupid* IMHO) to fork, rebuild, and maintain a few more hundred
packages only because they happen to provide a systemd unit file for
those systems where systemd is used.
libsystemd0 is used by some daemons to verify if systemd is running or
not. If it's not, libsystemd is *totally* *harmless*.
HND
KatolaZ

greenjeans · 2018-03-05 21:53:52

Good info Golinux!

Lots of examples of this, I personally try to NOT use Pulseaudio, but installing VLC drags in libpulse, not because VLC won't work on ALSA, but so it can communicate if need be with another machine on a network that does use it. So in practice it's never used expect for the above scenario. I simply deleted most of the pulse files and made it into a dummy package. Not that it wasn't a dummy to start with.

oui · 2018-06-04 19:19:50

Hi
I did check in my installation (in Jessie):

sudo apt-get --no-install-recommends install sudo gpm clex xinit xserver-common xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-mouse xserver-xorg-video-modesetting xserver-xorg-video-intel x11-apps x11-common x11-session-utils x11-utils x11-xkb-utils x11-xserver-utils xfonts-base xfonts-encodings xfonts-scalable xfonts-utils xserver-xorg xserver-xorg-video-vmware xterm menu 9menu ratpoison jwm choosewm merkaartor mpv deborphan rxvt alsa-base alsa-tools alsa-utils alsa-tools-gui pulseaudio cups-client cups-common cups-server-common ssl-cer

(I did only add manually QtWeb and Seamonkey, each the last proposed download from the sites of both, and libflashplayer.so from my last (32 bit) Debian Jessie installation...)

I did really find in my absolutely minimal installation a subdir /lib/systemd with an impressive content!

Jafa · 2020-12-06 00:52:00

Those are called 'stubs' in computer science. They are put there as a deprecation to keep apps & utilities that reference them from failing catastrophically. (It's kinda like having a "guest" bedroom, but never inviting anyone to spend the night (which demonstrates that you are socially competent, but you don't actually have to go there)).

Last edited by Jafa (2020-12-06 01:16:20)

swarfendor437 · 2021-01-24 13:49:15

I've had some issues with Jitsi in terms of sound and finally had to install the Pulse package for ALSA to get it working (sound) whilst in a Jitsi meeting. I don't use VLC any more. The only media players on the system are: mpv media player, SM Player, Dragon Player, Videos. Appears I have Pulse Audio Volume Control but I think I had to install it too regarding the Jitsi issue.

mckaygerhard · 2021-01-27 19:12:28

golinux wrote:

Why are there systemd files present in Devuan? That question has been asked and answered several times including recently on the DNG mail list at the end of this post:

"this post" are broken!

Lurker - failed to render page:
Database message source pull failure (not found):
The specified message has been deleted.

what a shame.. more and more failes?

zapper · 2021-01-27 23:59:56

Jafa wrote:

Those are called 'stubs' in computer science. They are put there as a deprecation to keep apps & utilities that reference them from failing catastrophically. (It's kinda like having a "guest" bedroom, but never inviting anyone to spend the night (which demonstrates that you are socially competent, but you don't actually have to go there)).

Sweet necro, its been like over 2 years...

Though why Swar also did so... idk.

Though his wasn't 2 years.

Edit: Should this be locked?

Last edited by zapper (2021-01-28 00:03:08)

mckaygerhard · 2021-01-28 01:03:54

zapper wrote:

Edit: Should this be locked?

is it necessary to ask.?.. broken links open forum threads .. puff

I remember the old forum and the disappointment of the maintainer, at least he put heart into it... in good manner I say that so much filtering and the same bureaucracy that we hate in debian seems to be present in devuan..

my most recent contribution was the improvement at the courier suite.. i made backport pacakges of in venenux repos that are working in devuan of course

bgstack15 · 2021-01-28 15:41:14

To be on topic, and probably to repeat earlier stuff which I'm not bothering to read: A lot of packages drop files into systemd locations. It doesn't harm a system to have /usr/lib/systemd/system/$FOOBAR.service as a file. It just doesn't help either.

There's rumblings of a devuan-sanity-systemctl package that will provide a systemctl translator script to actually provide the real behavior from the "systemctl" invocations, for the Ceres (unstable) release, but I don't know if that's going anywhere. If you download that yourself, be sure to put it in /usr/bin and not /usr/sbin. But be advised that the script will just run the real "service $FOOBAR stop" commands and not actually use the /usr/lib/systemd/system/$FOOBAR.service service entries. It isn't systemd, after all.

If you would like to contribute to how Devuan operates, we meet weekly. You can read the announcement for how to attend the meetings: https://lists.dyne.org/lurker/message/2 … 7c.en.html.

dice · 2021-01-28 15:50:57

bgstack15 wrote:

To be on topic, and probably to repeat earlier stuff which I'm not bothering to read: A lot of packages drop files into systemd locations. It doesn't harm a system to have /usr/lib/systemd/system/$FOOBAR.service as a file. It just doesn't help either.
There's rumblings of a devuan-sanity-systemctl package that will provide a systemctl translator script to actually provide the real behavior from the "systemctl" invocations, for the Ceres (unstable) release, but I don't know if that's going anywhere. If you download that yourself, be sure to put it in /usr/bin and not /usr/sbin. But be advised that the script will just run the real "service $FOOBAR stop" commands and not actually use the /usr/lib/systemd/system/$FOOBAR.service service entries. It isn't systemd, after all.
If you would like to contribute to how Devuan operates, we meet weekly. You can read the announcement for how to attend the meetings: https://lists.dyne.org/lurker/message/2 … 7c.en.html.

This reads to me like damage control. Systemd is causing devuan to mitigate the blow systemd is going to strike in the future?

mckaygerhard · 2021-01-29 21:46:16

bgstack15 wrote:

To be on topic, and probably to repeat earlier stuff which I'm not bothering to read: A lot of packages drop files into systemd locations. It doesn't harm a system to have /usr/lib/systemd/system/$FOOBAR.service as a file. It just doesn't help either.
If you would like to contribute to how Devuan operates, we meet weekly. You can read the announcement for how to attend the meetings: https://lists.dyne.org/lurker/message/2 … 7c.en.html.

network-mananger still cause some problems.. and now i found systemd files present in some non managed devuan packages..

i search at the search tool site of devuan and we can found several systemd files present in the system:

https://pkginfo.devuan.org/xsl-bin/pack … n=0.69.0-2

it seems that debhelper 11+ integrates dh_systemd, devuan developers need to manage the buils of this and remove that code.. most easy way is an auto_dh_systemd empty section in debian/rules of rebuild debian merged packages..

there also other amprolla merged ones that are not managed by devuan such as the famous courier-imad so widelly used:

i search at the search tool site of devuan and we can found several systemd files present in the system:

https://pkginfo.devuan.org/xsl-bin/pack … .6+1.0.6-1 it put a /lib/systemd/system/courier-imap.service file and also trigger into postinstall file..

security updates need also be tracked i noted the delayed way of devuan respect the souorce of the packages (debian)

zapper · 2021-01-30 10:13:04

mckaygerhard wrote:

bgstack15 wrote:
To be on topic, and probably to repeat earlier stuff which I'm not bothering to read: A lot of packages drop files into systemd locations. It doesn't harm a system to have /usr/lib/systemd/system/$FOOBAR.service as a file. It just doesn't help either.
If you would like to contribute to how Devuan operates, we meet weekly. You can read the announcement for how to attend the meetings: https://lists.dyne.org/lurker/message/2 … 7c.en.html.
network-mananger still cause some problems.. and now i found systemd files present in some non managed devuan packages..
i search at the search tool site of devuan and we can found several systemd files present in the system:
https://pkginfo.devuan.org/xsl-bin/pack … n=0.69.0-2
it seems that debhelper 11+ integrates dh_systemd, devuan developers need to manage the buils of this and remove that code.. most easy way is an auto_dh_systemd empty section in debian/rules of rebuild debian merged packages..
there also other amprolla merged ones that are not managed by devuan such as the famous courier-imad so widelly used:
i search at the search tool site of devuan and we can found several systemd files present in the system:
https://pkginfo.devuan.org/xsl-bin/pack … .6+1.0.6-1 it put a /lib/systemd/system/courier-imap.service file and also trigger into postinstall file..
security updates need also be tracked i noted the delayed way of devuan respect the souorce of the packages (debian)

For once, I agree, NetworkManager is going to cause problems.

Connman and wicd are good workarounds for now. Dhcpcd-gtk would be useful, only problem is, I don't know to get it running in devuan.

In Hyperbola its super simple.

Devuan/Debian distros, not so much...

mckaygerhard · 2021-01-30 21:31:53

zapper wrote:

mckaygerhard wrote:
it seems that debhelper 11+ integrates dh_systemd, devuan developers need to manage the buils of this and remove that code.. most easy way is an auto_dh_systemd empty section in debian/rules of rebuild debian merged packages..
there also other amprolla merged ones that are not managed by devuan such as the famous courier-imad so widelly used:
i search at the search tool site of devuan and we can found several systemd files present in the system:
https://pkginfo.devuan.org/xsl-bin/pack … .6+1.0.6-1 it put a /lib/systemd/system/courier-imap.service file and also trigger into postinstall file..
security updates need also be tracked i noted the delayed way of devuan respect the souorce of the packages (debian)
For once, I agree, NetworkManager is going to cause problems.
Connman and wicd are good workarounds for now. Dhcpcd-gtk would be useful, only problem is, I don't know to get it running in devuan.
In Hyperbola its super simple.
Devuan/Debian distros, not so much...

well i was talking about two things in same way, networ-manager problem is not take a program and make to work.. wicd are only eth0/wifi and conmman is not so active developed.. well only end users will be affected and in those limited programs devuan will be used by hackers only ..

we need to make it work the network-manager package, devuan and debian packagers must work togetter as winbuntu does, yeah sounds nasty but well devuan relies on debian sources

fsmithred · 2021-02-24 21:39:20

Removing systemd service files is the equivalent of removing sysvinit scripts. Doing so breaks interoperability and we absolutely should not be doing that. It also smacks of hypocracy.

build-deps are another story. The current advice is to build in a chroot so you don't contaminate your system. Maybe someday we'll have enough devs to fork everything.

mckaygerhard · 2021-02-25 00:06:48

fsmithred wrote:

Removing systemd service files is the equivalent of removing sysvinit scripts. Doing so breaks interoperability and we absolutely should not be doing that. It also smacks of hypocracy.
build-deps are another story. The current advice is to build in a chroot so you don't contaminate your system. Maybe someday we'll have enough devs to fork everything.

nonsense.. i removed complety those files in jessie.. was a hard job of course and i not are a fashion software stupid guy so my jessie will be here almost 9 years more, cos i not need updates if i do not run server and nobody break a double nat protected provider of internet

fsmithred · 2021-02-25 10:36:24

mckaygerhard wrote:

fsmithred wrote:
Removing systemd service files is the equivalent of removing sysvinit scripts. Doing so breaks interoperability and we absolutely should not be doing that. It also smacks of hypocracy.
build-deps are another story. The current advice is to build in a chroot so you don't contaminate your system. Maybe someday we'll have enough devs to fork everything.
nonsense.. i removed complety those files in jessie.. was a hard job of course and i not are a fashion software stupid guy so my jessie will be here almost 9 years more, cos i not need updates if i do not run server and nobody break a double nat protected provider of internet

It's not nonsense at all. You miss the point. I think it's fine for you to modify your system any way you want. The ability to do that is one of the best features of linux. I think it would be very bad if debian made it official policy to remove all sysvinit scripts. Likewise, I think it would be very bad if devuan made it official policy to remove all systemd service files.

mckaygerhard · 2021-02-26 13:28:37

fsmithred wrote:

mckaygerhard wrote:
nonsense.. i removed complety those files in jessie.. was a hard job of course and i not are a fashion software stupid guy so my jessie will be here almost 9 years more, cos i not need updates if i do not run server and nobody break a double nat protected provider of internet
It's not nonsense at all. You miss the point. I think it's fine for you to modify your system any way you want. The ability to do that is one of the best features of linux. I think it would be very bad if debian made it official policy to remove all sysvinit scripts. Likewise, I think it would be very bad if devuan made it official policy to remove all systemd service files.

debian wheeze has systemd but no units file in first prevous release and works so is nonsense, there's other debian based system that complety removed systemd and use by default sisvinit files.. in fact debian policy WAS to remove complety the sysvinit files until some months ago.. so dont talk if you dont know what are talking

of course removing all systemd units will need a complete reimplementation in sysv style, by example runtime dirs and tmp dirs are now managed by systemd proceses.. as happened in php .. the init sysvinit script now uses the systemd creation of directory process.. so if you remove the units files dont harm in nothing the process but if you removed the systemd infraestructure of course you must turn back all the behaviour of sysvinit processes

based on that i just said.. it seems that devuan are not really systemd free XD

Last edited by mckaygerhard (2021-02-26 13:29:08)

dice · 2021-02-26 14:00:16

^ You can remove systemd all you like but if programs being built upstream are dependant on systemd then it is a bit of a conundrum to say that devuan is not really systemd free imo. Remember that devuan is a fork of debian! Its not like voidlinux or slackware or puppy linux. The same can be said for artix linux as they use the same package management as archlinux who use systemd for the init system.

Last edited by dice (2021-02-26 14:00:56)

mckaygerhard · 2021-02-26 14:53:09

dice wrote:

^ You can remove systemd all you like but if programs being built upstream are dependant on systemd then it is a bit of a conundrum to say that devuan is not really systemd free imo. Remember that devuan is a fork of debian! Its not like voidlinux or slackware or puppy linux. The same can be said for artix linux as they use the same package management as archlinux who use systemd for the init system.

umm in this way.. we are moving to sysvinit.. not passing to another incmpatible environment.. so sysv.-init does not need all the systemd units.. but need some systemd proceses and programs.. so it not complety free and so then we will relly in systemd for evert? so we must use debian? .. my head are not in headhache XD..

i really hate systemd and i must work with it! puff

dice · 2021-02-26 15:15:16

mckaygerhard wrote:

dice wrote:
^ You can remove systemd all you like but if programs being built upstream are dependant on systemd then it is a bit of a conundrum to say that devuan is not really systemd free imo. Remember that devuan is a fork of debian! Its not like voidlinux or slackware or puppy linux. The same can be said for artix linux as they use the same package management as archlinux who use systemd for the init system.
umm in this way.. we are moving to sysvinit.. not passing to another incmpatible environment.. so sysv.-init does not need all the systemd units.. but need some systemd proceses and programs.. so it not complety free and so then we will relly in systemd for evert? so we must use debian? .. my head are not in headhache XD..
i really hate systemd and i must work with it! puff

Well that is what devuan is about. packages have been modified and maintained to work for the devuan environment, for instance libpam-elogind over libpam-systemd.You clearly do not understand...

golinux · 2021-02-26 15:51:26

@mckaygerhard . . . if Devuan does not suit you, feel free to go elsewhere.

mckaygerhard · 2021-02-27 16:38:33

golinux wrote:

@mckaygerhard . . . if Devuan does not suit you, feel free to go elsewhere.

you always predecible respoonse.. is not rare devuan has some problems.. lkest continue guys wit this productive thread.. wheere was ?

mckaygerhard · 2021-02-27 17:03:50

dice wrote:

Well that is what devuan is about. packages have been modified and maintained to work for the devuan environment, for instance libpam-elogind over libpam-systemd.You clearly do not understand...

no I get it, but we want to be purists and we can't be purists.. we are not a free systemd distro really.. because we can't.. .. we depends on a distro that already is systemd focused.. so maybe a new way is the best.. ? cos the situation is so ironic

Last edited by mckaygerhard (2021-02-27 17:05:49)

dice · 2021-02-28 15:33:00

mckaygerhard wrote:

dice wrote:
Well that is what devuan is about. packages have been modified and maintained to work for the devuan environment, for instance libpam-elogind over libpam-systemd.You clearly do not understand...
no I get it, but we want to be purists and we can't be purists.. we are not a free systemd distro really.. because we can't.. .. we depends on a distro that already is systemd focused.. so maybe a new way is the best.. ? cos the situation is so ironic

debian is not a "distro" it is an operating system. Devuan does not use systemd as init.

brocashelm · 2021-02-28 20:32:43

Debian is without a doubt a distro. Technically speaking, GNU is the operating system that nearly all of the distros are produced from. We just call it "Linux" because it's more conventional, despite it fundamentally being nothing more than a kernel.

The officially official Devuan Forum!

#1 2018-03-04 20:17:54

Why are systemd files present in Devuan?

#2 2018-03-05 21:53:52

Re: Why are systemd files present in Devuan?

#3 2018-06-04 19:19:50

Re: Why are systemd files present in Devuan?

#4 2020-12-06 00:52:00

Re: Why are systemd files present in Devuan?

#5 2021-01-24 13:49:15

Re: Why are systemd files present in Devuan?

#6 2021-01-27 19:12:28

Re: Why are systemd files present in Devuan?

#7 2021-01-27 23:59:56

Re: Why are systemd files present in Devuan?

#8 2021-01-28 01:03:54

Re: Why are systemd files present in Devuan?

#9 2021-01-28 15:41:14

Re: Why are systemd files present in Devuan?

#10 2021-01-28 15:50:57

Re: Why are systemd files present in Devuan?

#11 2021-01-29 21:46:16

Re: Why are systemd files present in Devuan?

#12 2021-01-30 10:13:04

Re: Why are systemd files present in Devuan?

#13 2021-01-30 21:31:53

Re: Why are systemd files present in Devuan?

#14 2021-02-24 21:39:20

Re: Why are systemd files present in Devuan?

#15 2021-02-25 00:06:48

Re: Why are systemd files present in Devuan?

#16 2021-02-25 10:36:24

Re: Why are systemd files present in Devuan?

#17 2021-02-26 13:28:37

Re: Why are systemd files present in Devuan?

#18 2021-02-26 14:00:16

Re: Why are systemd files present in Devuan?

#19 2021-02-26 14:53:09

Re: Why are systemd files present in Devuan?

#20 2021-02-26 15:15:16

Re: Why are systemd files present in Devuan?

#21 2021-02-26 15:51:26

Re: Why are systemd files present in Devuan?

#22 2021-02-27 16:38:33

Re: Why are systemd files present in Devuan?

#23 2021-02-27 17:03:50

Re: Why are systemd files present in Devuan?

#24 2021-02-28 15:33:00

Re: Why are systemd files present in Devuan?

#25 2021-02-28 20:32:43

Re: Why are systemd files present in Devuan?

Board footer