Does Gentoo focus currently more on systemd?

[sincorchetes]

Hello all,

Currently, I see some changes like systemd-utils replacing udev package. What is the next step?

* viewtopic-t-1148246-highlight-systemdutils.html
* viewtopic-t-1148594-highlight-udev.html

Thanks.

[NeddySeagoon]

sincorchetes,

systemd-utils is the three? existing separate packages rolled into one for ease of maintenance.
Some changes need all the packages to be updated together.

Its easier for maintainers and more robust for users, since users no longer have the risk of getting a partial update.

Its a naming change. There is no change in functionality for users.

[Ionen]

Yes, it's not a replacement, systemd-utils[udev] installs exactly the same that sys-fs/udev used to.

This is just a combined package to install utilities from systemd's tarball (which sys-fs/udev uses as well), without requiring systemd itself. The tarball notably require a patchset and has many identical dependencies making it simpler to maintain a single ebuild (rather sys-fs/udev + systemd-boot + systemd-tmpfiles).

And these packages solely exist to help support installs not using systemd as init system, can't install systemd-utils on a systemd profile

[spyderco]

sincorchetes,

systemd-utils is the three? existing separate packages rolled into one for ease of maintenance.
Some changes need all the packages to be updated together.

Its easier for maintainers and more robust fol users, since users no longer have the risk of getting a partial update.

Its a naming change. There is no change in functionality for users.

If it's not going to systemd, why did they remove opentmpfiles by closing the project and adding systemd packages to the users we have open-rc?

Open-rc users don't want anything from systemd, we want to have the option to choose what to have on our system, that's what we like about gentoo, the option to be able to make the system the way we users want it.

if we try to blocking the sys-apps/systemd package forces us to install systemd, a lot of gentoo users are leaving the distribution because of this, we don't like the change of having to compile something related to systemd on our systems.

so we use open-rc to avoid that on all levels, but that's changing as we can't completely block it, and these things didn't happen before, why is all this happening?

[GDH-gentoo]

If it's not going to systemd, why did they remove opentmpfiles by closing the project and adding systemd packages to the users we have open-rc?

opentmpfiles was abandoned by its own developers, because of a perceived vulnerability that they think cannot be fixed without a complete rewrite.

[spyderco]

If it's not going to systemd, why did they remove opentmpfiles by closing the project and adding systemd packages to the users we have open-rc?

opentmpfiles was abandoned by its own developers, because of a perceived vulnerability that they think cannot be fixed without a complete rewrite.

I know, but the work of systemd has been left to us, we want complete independence from systemd.

And respect for open-rc users with an independent port of systemd,

Both by users who have relied on gentoo for years, like the ones I respect in the past. open-rc itself and everything it stands for, and what does it stand for? freedom!

[trilithium]

I have an issue with systemd-tmpfiles, which I think is based on a flawed concept; if a subsystem (e.g. a daemon) relies on certain parts of the filesystem being set up in a certain way it should arrange this as part of its initialization to keep subsystem concerns and configuration together. Inserting middleware here needlessly increases system complexity and invites safety issues.

[GDH-gentoo]

[...] an independent port of systemd, [...]

Someone has to write that independent port, and that requires time and effort.

[...] and what does it stand for? freedom!

This looks to me like a concrete action to support that freedom:

And these packages solely exist to help support installs not using systemd as init system, [...]

(And / or not using GNU libc, I might add)

[...] if a subsystem (e.g. a daemon) relies on certain parts of the filesystem being set up in a certain way it should arrange this as part of its initialization to keep subsystem concerns and configuration together. Inserting middleware here needlessly increases system complexity and invites safety issues.

I agree.

[ian.au]

I have an issue with systemd-tmpfiles, which I think is based on a flawed concept; if a subsystem (e.g. a daemon) relies on certain parts of the filesystem being set up in a certain way it should arrange this as part of its initialization to keep subsystem concerns and configuration together. Inserting middleware here needlessly increases system complexity and invites safety issues.

Well, it sheets back to whether or not you want / need the convenience of udev; that's their choke-point, or it will be when they introduce a runtime dependency on systemd anyway. The dev's here take a lot of imo undeserved flack for the simple reason that there are nowhere near enough of them to compete with RH & Co. When all the distros went systemd it was inevitable that the development effort would move that way. When they flipped Debian, in particular, it had ramifications for Gentoo.

It is what it is, and we'll likely see more of these shims as time goes by, unless / until someone wants to rewrite and maintain a udev alternative.

Or you decide to set up without it, for which I'm considering setting up an https://wiki.gentoo.org/wiki/Old_Fashio ... oo_Install because it's the only way to be sure to avoid assimilation if that's your choice. I know a lot of the old pro's here have quietly gone that way on their own. Fortunately for the rest of us, we have Neddy to shine a torch on some of these ancient and arcane practices

I suspect it's also a fair bit more work to set up and maintain, and you have to be prepared to be a real sysadmin to make it all work. I'm interested to see how much, and expect the stability and simplified debugging of a better understood system probably offsets this over time.

[Hu]

Open-rc users don't want anything from systemd, we want to have the option to choose what to have on our system, that's what we like about gentoo, the option to be able to make the system the way we users want it.

if we try to blocking the sys-apps/systemd package forces us to install systemd, a lot of gentoo users are leaving the distribution because of this, we don't like the change of having to compile something related to systemd on our systems.

so we use open-rc to avoid that on all levels, but that's changing as we can't completely block it, and these things didn't happen before, why is all this happening?

You are free not to run systemd-tmpfiles - if you avoid all packages that need a tmpfiles processor to run during early boot, for the purpose of creating their pseudo-persistent directories, or if you install an alternative tmpfiles processor. opentmpfiles was such a processor, but as noted, it was abandoned.

You are free to avoid systemd-udevd - if you avoid all packages that expect a working userspace-device-management daemon, or install a udevd competitor that provides the required features.

Due to the behavior of the systemd project (with regard to adding new functionality, so matching their features becomes a running target), in conjunction with the behavior of other upstream projects that have elected to depend on systemd's tools, the options for avoiding systemd tools may require you to make some hard choices. Gentoo lets you make those choices, if you are prepared to live with the consequences.

You could, if you wish, develop and maintain feature-compatible competitors to the systemd tools, or find someone else who is doing so and help them. At this time, the Gentoo developers have not chosen to take on such a burden, so the best they can do for you is to offer you cut down parts of the systemd packages, allowing you to satisfy these particular feature requirements without running the full systemd environment.

[NeddySeagoon]

spyderco,

I don't have any systemd components on my desktop install.
You probably wouldn't like it though but I have a long memory and it works for me.

[lumaro]

Hi all,

At this moment i left Gentoo. I disklike systemd. The package systemd-tmpfiles replaced opentmpfiles, now systemd-utils turn off eudev.

OpenRC (init and a few components) was originally developed by Gentoo. Now, this project was dropped. Sincerely, I don't recognize Gentoo. Gentoo was the first project that initially creates the alternative vs systemd. If it drops its own projects in favor of systemd, What happens with the rest of the users does not want systemd in your system?


If the tool forces the user to do things a particular way, then the tool is working against, rather than for, the user. We have all experienced situations where tools seem to be imposing their respective wills on us. This does not follow the Gentoo philosophy.

https://www.gentoo.org/get-started/philosophy/


I sincerely believe that this philosophy, whose author is Daniel Robbins, who abandoned the project and is contrary to systemd, no longer has any value.
-------------
NeddySeagoon wrote:
spyderco,

I don't have any systemd components on my desktop install.
You probably wouldn't like it though but I have a long memory and it works for me.

---------------
Do you have your system without systemd-* packages? Please, share the solution.

[NeddySeagoon]

lumaro,

There is Old Fashioned Gentoo Install from 2013 and I've started a new document based on migrating that to new hardware.
YeOldeGentoo 2021 Edition

I patch ebuilds to not want things so that they will build. The gentoo-static overlay is often out of date, things may build and not run.
They will have missing functionality.

[sincorchetes]

I think the systemd was a poisoned candy.

In the beginning, systemd just will be service management and the concept was very awesome. However, this idea is like a monster or another meaning of "services manager".

systemd timers replacing cron
systemd-boot replacing grub
systemd-udev
systemd-userdb what f*cking needed?
systemd-home for what?
systemd...systemd...blablabla

Why the users do have to use these utilities, in this case, systemd-utils instead of looking for alternatives... So, What happens with Devuan or Void Linux that does not use systemd utilities? I think is trying to justify "We do not want to work anymore this, it's more easily use these tools". What's the next? Replacing slowly more pieces of OpenRC to use systemd into just only you use only a systemd profile?

[Hu]

As I wrote above, Gentoo is reflecting the decisions and limitations of upstream packages. If opentmpfiles had been fixed rather than abandoned[1], then there is a decent chance that systemd-tmpfiles would not have been introduced on openrc systems. If maintaining eudev as a fork of systemd-udevd had demonstrated a meaningful payoff, the Gentoo developers might not have chosen to push openrc users to systemd-udevd. If systemd-udevd / systemd-tmpfiles had not required so much duplicative effort to maintain, the Gentoo developers might not have chosen to combine them into a single package. In every case, the developers were given the choice of: disable some functionality that most users want; ship a portion of systemd; reimplement that portion; force users onto systemd. If you want to stop the systemd encroachment, convince upstream packages to stop adding hard dependencies on systemd features.

[1]: From what I have read, fixing it was deemed much harder than adapting the systemd-tmpfiles code to work as a standalone package. The relevant developers chose the path of less resistance, because at the time, systemd-tmpfiles did not have significant enough drawbacks to argue against using it.

[sam_]

As I wrote above, Gentoo is reflecting the decisions and limitations of upstream packages. If opentmpfiles had been fixed rather than abandoned[1], then there is a decent chance that systemd-tmpfiles would not have been introduced on openrc systems. If maintaining eudev as a fork of systemd-udevd had demonstrated a meaningful payoff, the Gentoo developers might not have chosen to push openrc users to systemd-udevd. If systemd-udevd / systemd-tmpfiles had not required so much duplicative effort to maintain, the Gentoo developers might not have chosen to combine them into a single package. In every case, the developers were given the choice of: disable some functionality that most users want; ship a portion of systemd; reimplement that portion; force users onto systemd. If you want to stop the systemd encroachment, convince upstream packages to stop adding hard dependencies on systemd features.

[1]: From what I have read, fixing it was deemed much harder than adapting the systemd-tmpfiles code to work as a standalone package. The relevant developers chose the path of less resistance, because at the time, systemd-tmpfiles did not have significant enough drawbacks to argue against using it.

This is all true, but I'd like to add:

• eudev still exists and you can still use it, as a new group of folks are maintaining it
• if someone does start maintaining opentmpfiles, we're happy to reconsider and look at switching back to it in Gentoo. It was the opentmpfiles maintainers that decided they didn't see a point in fixing its issues given it'd need a full rewrite in something like C. Feel free to volunteer to help with that if you're interested.
• OpenRC is going nowhere and is still actively maintained - the "not a Gentoo project" thing is just a decision by its maintainers to make sure it caters for all distros and e.g. BSDs which want to use it, and it's been like that for many many years.

[figueroa]

I would like to point out that those who presume to speak (strongly) for all OpenRC users should not do so and they don't reflect any reasonable unanimity. I am one of those users of OpenRC who does not want to use systemd, but I have no objection to selectively using pieces from the systemd project (or any other project) make practical use and maintenance of a desktop computer easier.

None of the parts borrowed from systemd seem excessive or make my systems behave like I'm using systemd. The initial news leaked about the repackaging of these little pieces as a single package seemed confusing to me, but I easily understood what was happening and I enthusiastically support the transition.

I'm a happy Gentoo user. Thank you developers, maintainers, and moderators. I think you are doing great things for the Gentoo community and the greater Linux community.

[sergiotarxz]

I am also a proud OpenRC user, but I don't have strong feelings about udev or other systemd modules being brought to Gentoo if they can do good and specially if no alternative is available but have a permanently broken/old/hard to maintain system.

Anyway eudev was systemd code adapted to run on openrc anyway so if systemd takes care of that better for everybody, I think.

I think that is not Gentoo what is changing but rather that the whole GNU/Linux environment is growing to handle greater complexity instead and some pieces of
the system are hard or boring to make twice.

I think it is worth saying that the phone niche of GNU/Linux it is bringing a new perspective to what we do expect GNU/Linux to be.

I am not saying that choice is not important but rather that we can choose rather to fight the battles that really matter to make the free software community grow.

Probably a udev clone or reimplementation can be less productive to get GNU/Linux in the people's pocket than making free software applications that make
a difference against the privative choices.

Who knows, just a random thought.

[szatox]

I think that is not Gentoo what is changing but rather that the whole GNU/Linux environment is growing to handle greater complexity instead and some pieces of the system are hard or boring to make twice.

It surely is, yet it brings that famous quote to my mind:
"If you keep improving something long enough, you'll inevitably break it"

That's the primary reason I see behind "The NIH Syndrome", standard proliferation and similar.
Anyone remembers KDE 3.5 yet? It was a really well polished, but got scrapped for sake of completely unusable (at the time) KDE 4, and that's how I moved to LXDE.
Talking about udev: the kernel already knows what devices exist in the system. It can even create nodes by mounting devtmpfs. Udev fixes permissions, right? Well, mdev can do that too. Of course, mdev is on a side-line, so one would have to write the config by himself.
What else needs to be done there? Renaming network interfaces? Well, back in the days network interface names were perfectly predictable without udev. In fact, I still find udev's names less predictable than kernel-generated ones, even though they _can_ change e.g. on kernel version bump.

systemd-tmpfiles - wait, what? What even is this thing? We've had tmpfs for ages, and it worked with a simple mount. Is it a daemon now? What happened when I wasn't paying attention?

[Zucca]

I would like to point out that those who presume to speak (strongly) for all OpenRC users should not do so and they don't reflect any reasonable unanimity. I am one of those users of OpenRC who does not want to use systemd, but I have no objection to selectively using pieces from the systemd project (or any other project) make practical use and maintenance of a desktop computer easier.

I recognize myself as a part of this (OpenRC+systemd-parts) group too.

If there are enough those who don't want to have any systemd parts in their system, I think it would be possible to create an extra (community) repository which would contain a profile for totally-systemd-free (while at it, also *kit and pam-free) gentoo and some accompanying packages for it.
Is there such repo/overlay already?

I, for sure, would try it at least on some of my PCs.

EDIT: Added clarification.

[sam_]

[...]
systemd-tmpfiles - wait, what? What even is this thing? We've had tmpfs for ages, and it worked with a simple mount. Is it a daemon now? What happened when I wasn't paying attention?

tmpfiles are configuration files which are processed by a one-off service (not a daemon, just a process which runs at boot then exits) to create needed temporary directories with the correct permissions and owners. If /run and friends are cleared on reboot (which they will be if on tmpfs), something has to re-create them. There are issues with re-creating them safely and correctly within init scripts (see below).

While systemd ended up choosing this approach to avoid not having to put these details in its unit files I think, the reason OpenRC started using them was because checkpath and other methods (like chown, etc) within init scripts ended up being extremely error prone. The use of traditional chown and so on led to several CVEs in init scripts.

(Aside: supposing OpenRC init script authors choose to continue using e.g. checkpath etc, which is fine, they need to then do more work rather than just using the e.g. tmpfiles config files used in other distributions and for systemd installations. It's a lot easier to actually help people continue using OpenRC by making it harder to screw up an init script.)

This is a non-exhaustive list (see the CVEs section) of the ones found by mjo (a Gentoo developer who indeed uses OpenRC heavily (don't think he uses systemd at all)):

• CVE-2017-18284 - Gentoo app-backup/burp privilege escalation via PID file manipulation
• CVE-2017-18226 - Gentoo net-im/jabberd2 privilege escalation via PID file manipulation
• CVE-2017-18225 - Gentoo net-im/jabberd2 root privilege escalation via user-owned executables
• CVE-2017-18240 - Gentoo app-admin/collectd privilege escalation via PID file manipulation
• CVE-2017-16638 - net-misc/vde root privilege escalation via OpenRC service script
• CVE-2017-15945 -dev-db/mysql, dev-db/mariadb, dev-db/percona-server, dev-db/mysql-cluster, and dev-db/mariadb-galera root privilege escalation via chown in ebuild phase functions
• CVE-2017-14730 - app-admin/logstash-bin root privilege escalation via init script
• CVE-2017-14483 - Gentoo dev-python/flower privilege escalation via PID file manipulation
  [...]

I am also a proud OpenRC user, but I don't have strong feelings about udev or other systemd modules being brought to Gentoo if they can do good and specially if no alternative is available but have a permanently broken/old/hard to maintain system.

Anyway eudev was systemd code adapted to run on openrc anyway so if systemd takes care of that better for everybody, I think.
[snip].

This is a good point and one I make often. I'm not at all against people writing an alternative which fits in well (please do write one!). Adopting things which make supporting OpenRC easier while not compromising on its principles mean that OpenRC lives on and there's either reduced or no burden on maintainers.

I would like to point out that those who presume to speak (strongly) for all OpenRC users should not do so and they don't reflect any reasonable unanimity. I am one of those users of OpenRC who does not want to use systemd, but I have no objection to selectively using pieces from the systemd project (or any other project) make practical use and maintenance of a desktop computer easier.

None of the parts borrowed from systemd seem excessive or make my systems behave like I'm using systemd. The initial news leaked about the repackaging of these little pieces as a single package seemed confusing to me, but I easily understood what was happening and I enthusiastically support the transition.

I'm a happy Gentoo user. Thank you developers, maintainers, and moderators. I think you are doing great things for the Gentoo community and the greater Linux community.

Thank you. And if somebody does write a component which works (even if it needs a bit of adaptation) like e.g. a non-systemd tmpfiles implementation (maybe a rewrite of opentmpfiles), we're happy to look at it. But we also have limited time which is why as a Gentoo developer, I can't do an infinite amount of work to fix non-problems while being shouted at to do more. There already aren't enough hours in the day to keep things working.

[K_Brown]

Well, it sheets back to whether or not you want / need the convenience of udev; that's their choke-point, or it will be when they introduce a runtime dependency on systemd anyway.

Gentoo provides sys-fs/static-dev for those of us who need not to use udev.

@system has no forced dependencies on udev so we are allowed to replace it with static-dev. Not the case with OpenRC being dependent on virtual/tmpfiles.

[sam_]

Well, it sheets back to whether or not you want / need the convenience of udev; that's their choke-point, or it will be when they introduce a runtime dependency on systemd anyway.

Gentoo provides sys-fs/static-dev for those of us who need not to use udev.

@system has no forced dependencies on udev so we are allowed to replace it with static-dev. Not the case with OpenRC being dependent on virtual/tmpfiles.

As per my above comments, it doesn't really make sense to "opt out" of tmpfiles unless you rewrite every init script using it to include permissions logic which, as I've mentioned, was extremely fragile (and dangerous) in the past. Such an effort would be a huge amount of work for very little gain. Nor is anybody volunteering to do that as far as I can see.

You can use package.provided if you really think you don't need it, or unmask opentmpfiles while it's still in tree. But I don't recommend that. You also forfeit the ability to complain about a service not acting properly at startup then.

[K_Brown]

You are free not to run systemd-tmpfiles - if you avoid all packages that need a tmpfiles processor to run during early boot, for the purpose of creating their pseudo-persistent directories, or if you install an alternative tmpfiles processor. opentmpfiles was such a processor, but as noted, it was abandoned.

Not true.
We are not free not to run systemd-tmpfiles since sys-apps/openrc rdepends on virtual/tmpfiles.

You are free to avoid systemd-udevd - if you avoid all packages that expect a working userspace-device-management daemon, or install a udevd competitor that provides the required features.

While it's possible to replace sys-fs/udev with sys-fs/static-dev, it's not the case with systemd-tmpfiles since sys-apps/openrc depends on virtual/tmpfiles and only systemd-tmpfiles satisfies such dependency.

The only need I can find in OpenRC for tmpfiles is in checkpath as explained in https://github.com/OpenRC/opentmpfiles/ ... -819483507 but it seems like overengineering what could bi acomplished with plain mkdir. Ownership on the new temporary directory could be acomplished with simple chown and chmod commands (without recursion parameters) while any conflicting /run subdirectory should never happen.

You could, if you wish, develop and maintain feature-compatible competitors to the systemd tools, or find someone else who is doing so and help them. At this time, the Gentoo developers have not chosen to take on such a burden, so the best they can do for you is to offer you cut down parts of the systemd packages, allowing you to satisfy these particular feature requirements without running the full systemd environment.

The problem is not the need for feature-compatible systemd tools, neither a solution could be providing them.
The only possible solution is not needing any systemd compatibility feature in OpenRC so it could be an effective sytemd replacement.

[sam_]

You are free not to run systemd-tmpfiles - if you avoid all packages that need a tmpfiles processor to run during early boot, for the purpose of creating their pseudo-persistent directories, or if you install an alternative tmpfiles processor. opentmpfiles was such a processor, but as noted, it was abandoned.

Not true.
We are not free not to run systemd-tmpfiles since sys-apps/openrc rdepends on virtual/tmpfiles.

See my previous post.

You are free to avoid systemd-udevd - if you avoid all packages that expect a working userspace-device-management daemon, or install a udevd competitor that provides the required features.

While it's possible to replace sys-fs/udev with sys-fs/static-dev, it's not the case with systemd-tmpfiles since sys-apps/openrc depends on virtual/tmpfiles and only systemd-tmpfiles satisfies such dependency.

The only need I can find in OpenRC for tmpfiles is in checkpath as explained in https://github.com/OpenRC/opentmpfiles/ ... -819483507 but it seems like overengineering what could bi acomplished with plain mkdir. Ownership on the new temporary directory could be acomplished with simple chown and chmod commands (without recursion parameters) while any conflicting /run subdirectory should never happen.

Init scripts lack logic to handle permissions because they rely on tmpfiles instead given it's far harder to get wrong. Also, your suggestion doesn't help the hardlink issue.

As I've said repeatedly, maintainers for opentmpfiles welcome.

You could, if you wish, develop and maintain feature-compatible competitors to the systemd tools, or find someone else who is doing so and help them. At this time, the Gentoo developers have not chosen to take on such a burden, so the best they can do for you is to offer you cut down parts of the systemd packages, allowing you to satisfy these particular feature requirements without running the full systemd environment.

The problem is not the need for feature-compatible systemd tools, neither a solution could be providing them.
The only possible solution is not needing any systemd compatibility feature in OpenRC so it could be an effective sytemd replacement.

See my previous post. It makes init scripts far easier to write and way, way less error prone. I do not think that making init scripts harder to safely write is a net win for OpenRC users, as it either means they're given poor-quality init scripts, or people simply don't bother writing them.