Solved. Why systemd-utils if I use openrc?

[tranquilcool]

I would like to ask why I should be bothered with systemd-utils at all.
What choice is it not permitting me to install_mask systemd directories without breaking my system!
No systemd war please, just the rationale.
_________________
this is a strange strange world.

[sMueggli]

https://www.gentoo.org/support/news-items/2022-04-19-systemd-utils.html

[logrusx]

[tranquilcool]

[kimchi_sg]

[tranquilcool]

[asturm]

Isn't it really more like that: You feel entitled to someone else giving you that warm feeling of choice by cutting out 'systemd' strings from every tool derived from it?

Install masks can break more than systemd tools (and have done so already, needlessly costing maintainers' time). "systemd" is not an exactly unique string if you think about it.

[tranquilcool]

[lars_the_bear]

I confess that I found this situation alarming when I started using Gentoo. The relationship between OpenRC and systemd-utils is actually documented, although it took me a while to understand why this relationship existed.

I don't think it's the job of the Gentoo maintainers to change the names of everything, just so I can get a warm, fuzzy feeling about having nothing with 'systemd' in the name. I don't like it -- but I know who's responsible, and it's not Gentoo.

BR, Lars.

[tranquilcool]

[tranquilcool]

[lars_the_bear]

[Koyan]

[Hu]

I know you are not the first person to ask just in these forums about this situation. The answers given to those prior posters are still applicable.

tranquilcool: what problem are you trying to solve here? Did you set an INSTALL_MASK without understanding its implications, and break something by blocking a critical file? I believe I've seen at least one case of someone using INSTALL_MASK="/lib/systemd/" only to later have the system break because /bin/udevadm was a symlink to /lib/systemd/systemd-udevd, and the latter was missing due to the INSTALL_MASK.

If you don't want to install sys-apps/systemd-utils, then you should use /etc/portage/package.mask to block it, and follow up with emerge --ask --verbose --depclean sys-apps/systemd-utils to remove it. Beware that many modern Linux programs assume use of udev, so you will likely need to make some compromises to get a system that works without udevd. It can be done, though. I encourage you to test such a removal on a non-critical system first, since successfully removing udevd, but not removing all dependencies on it, can easily leave you with a system that cannot boot on its own.

[lars_the_bear]

[tranquilcool]

Thanks @Hu, @lars_the_bear, @koyan

I fixed my broken system with eudev, which is what I was using before anyway. It still works for me.
I maybe missed the news item about these system links to systemd directories in case of install_mask systemd, if there was any.
And of course I prefer to go ahead with install_mask. It's okay with me.

As a side note, I was hoping someone could explain to me the bontà of these "strange, but legitimate" udev links when using systemd-utils, and how necessary they are in a linux system, suppose one inadvertently uses install_mask systemd.
It was never about systemd, which I don't use, and don't' hope to use. And I believe there should be no implications if one prefers to use and init system instead of another. The bad, according to me, is the mixing up of two different init systems.
Thanks all.
_________________
this is a strange strange world.

[asturm]

As a consequence, please consider not filing bugs in the future.

[tranquilcool]

[Hu]

sys-fs/eudev appears not to be available in the tree anymore. Any systems relying on it are therefore on borrowed time. Any bugs that are only reproducible when using an unsupported out-of-tree package are likely to be rejected.

As for the links, I think the way that the systemd project did those links looks weird, but it is retained in Gentoo because it does not break anything, and Gentoo has enough complexity without creating needless deviations from upstream. From what I recall of the links, they are necessary if you want udevd to work correctly.

[tranquilcool]

[Hu]

The correct way to avoid installing packages you don't want is to use package.mask to forbid installing them. Using INSTALL_MASK like this will still let Portage try to install systemd if a package dependency requires it, but pieces of it will be missing, with potentially confusing and subtle consequences.

[tranquilcool]

[Hu]

I think you are disagreeing with me, but I don't understand what you want done instead. I told you how to do this in a way that fails safely and clearly, with a nice error from Portage telling you that continuing would require violating your local policy of no-systemd. Using INSTALL_MASK fails messily and silently, with files missing and other packages misbehaving due to their absence.

[tranquilcool]

[eschwartz]

Using INSTALL_MASK without carefully understanding exactly what you are masking and why is dangerous and will lead to broken systems.

The string "systemd" is not inherently problematic and there is no reason to prevent its appearing in an installed system. Moreover, it is incredibly dangerous because, for example, what do you think you are going to do if some program such as sys-apps/portage contains a file in it:

/usr/lib/python3.12/site-packages/portage/util/systemdetails.py

And your INSTALL_MASK goes and deletes that file, and portage cannot collect information about the *details* of your *system*?

If you want to, I dunno, stop packages from installing a 4kb file called git-daemon@.service because you think the presence of a text file that goes unused is going to invite the moral evils of Red Hat's attempt at dominating Linux, then you do not have any right to lecture other people about "No systemd war please". Sorry.