Does Gentoo focus currently more on systemd?

[szatox]

@figueroa, this is a confirmation your message has been displayed on recipient's machine.
@asturm, why, thank you! It's really funny coming from you though.
@sam_, thank you for your work and dedication to the project.

Signing out.

[asturm]

So I guess I'll do my part of pointing finger here too: Asturm, please do not post just to provoke others.

Rejected. This lot does not get to crawl out of their hole and call people dishonest without a proportional reaction. Frequency and reliability of the "having to go to Funtoo" trope coming up makes it fine for me call their bluff, and everyone is free to choose their distribution anyway, who are we to try and pull them back.

[GDH-gentoo]

Can we not do this again, please? Avoiding provocative posts does help preventing escalation and locked threads, regardless of who thinks (s)he is right. sam_ seems to be able to do it.

Also, I see a moderator badge under Zucca's username, just saying.

I, and we overall in Gentoo, do in fact very much care about the non-systemd usecase.

BTW, thanks to everyone involved in packaging and stabilizing recent enough versions of skarnet.org packages (the s6 suite) and getting rid of the old ones, it was on my wish list.

[Zucca]

Can we not do this again, please? Avoiding provocative posts does help preventing escalation and locked threads

++

Locking a thread punishes (almost) everyone involved. Issuing temporary ban(s) on the other is usually much harder choice when it comes to topics like these where there are many different groups of participants.

In this case the best choice (in terms of moderation actions) would be to split out some of the "progressive" posts (mainly from sam_, mv, K_Brown) and lock the rest.

As for Asturm's comment - he knows how his comment is being seen and I refrain replying anything more than this.

Most of the time things tend to solve themselves.

@K_Brown: You may want to start a new topic for your patches to revive opentmpfiles. I think it would gather more those who are interested of that (sub)topic. ;)

[lumaro]

Hi all,

I currently maintain opentmpfiles and eudev, via a modified ebuild of the virtual/tmpfiles package where I edit out the absurd and unnecessary imposition of systemd-utils that comes with udev's obligation.

What will be the future of Gentoo, follow the steps dictated by init B (optional) or resume the course of init A (OpenRC), supporting the projects initiated by Gentoo. Have you really considered doing a community survey to find out what they want/we want?

I know that over time, everyone will end up conforming, but those who don't will surely leave the distribution, if it's what you want, you're getting it.

I do not want to make a flamewar of this post, it is only a wake-up call to freedom and common sense. The systemd issue is sensible and should be treated in a special way, is what I think. The least I expected is not to have to write and share a recipe for those of us who don't want to use systemd binaries, that should be Gentoo.

For those who want to continue with opentmpfiles and eudev, what I have done is modify the virtual/tmpfiles ebuild and create a local repo (which has priority), as well as unmask the opentmpfiles package.

https://wiki.gentoo.org/wiki/Creating_a ... repository

https://wiki.gentoo.org/wiki/Handbook:A ... repository.

The code is that of the tmpfiles-0-r1 version, then I add a mask so that the tmpfiles-0-r3 version is not updated, in short, a fudge, it is the solution that I have found.

Code: Select all

 $ ~ qlist -Iv systemd
 $ ~ qlist -Iv tmpfiles
sys-apps/opentmpfiles-0.2
virtual/tmpfiles-0-r3
 $ ~ ls -l /var/db/repos/
total 16
drwxr-xr-x 177 root root 8192 abr 10 20:20 gentoo
drwxr-xr-x   5 root root   53 jun  1 01:02 localrepo
drwxr-xr-x  30 root root 4096 abr 10 20:20 nymphos
drwxr-xr-x  13 root root  289 abr 10 20:20 ricerlay
drwxr-xr-x  10 root root  179 abr 10 20:20 setkeh

[Hu]

a modified ebuild of the virtual/tmpfiles package where I edit out the absurd and unnecessary imposition of systemd-utils that comes with udev's obligation.

systemd-utils does not obligate you to use udev. Many people who install it will want udev, but for eudev users, systemd-utils can be installed without udev.

What will be the future of Gentoo, follow the steps dictated by init B (optional) or resume the course of init A (OpenRC), supporting the projects initiated by Gentoo. Have you really considered doing a community survey to find out what they want/we want?

As discussed many times, the future of Gentoo is that it will provide what upstream offers. If the only viable upstream for tmpfiles is systemd, then systemd's tmpfiles will be what Gentoo offers. If some other project offers a tmpfiles processor that is compatible with systemd's tmpfiles, then that other project can also be offered as a provider for virtual/tmpfiles. As it stands, the last release of opentmpfiles is no longer acceptable, so it was removed. If someone were to fix it (which, by some accounts, would be a nearly complete rewrite), it could come back.

The least I expected is not to have to write and share a recipe for those of us who don't want to use systemd binaries, that should be Gentoo.

Is your opentmpfiles either (a) patched to support the latest (sometimes crazy) extensions to systemd's tmpfiles specification or (b) given an RDEPEND blocker to prohibit installing projects that rely on those extensions that were not available in the last upstream release of opentmpfiles? If no to both, you are setting yourself and your users up for weird bugs the first time they feed an extended tmpfiles configuration file to the old opentmpfiles processor that does not understand the latest extensions. What, if anything, do you do about the race conditions present in opentmpfiles?

[figueroa]

lumaro

systemd-utils is a perfectly workmanlike solution to provide udev, tmpfiles, (and other where needed) functionality for Gentoo OpenRC users. I'm thankful to Gentoo developers for adopting the best, most practical solutions from Linux upstream without blindly boycotting pieces of code based on prejudice against source of the project or the identity of the developer(s).

Branching off the mainstream with buggy, unsupported software for the sake of purity or freedom in an impractical, short-term, and dead-end direction. On the other hand, creating and maintaining sound alternative software for future adoption into the Gentoo tree for the benefit of all users would be in the best tradition of Open Source.

[pjp]

Is your opentmpfiles either (a) patched to support the latest (sometimes crazy) extensions to systemd's tmpfiles specification or (b) given an RDEPEND blocker to prohibit installing projects that rely on those extensions that were not available in the last upstream release of opentmpfiles? If no to both, you are setting yourself and your users up for weird bugs the first time they feed an extended tmpfiles configuration file to the old opentmpfiles processor that does not understand the latest extensions. What, if anything, do you do about the race conditions present in opentmpfiles?

In my opinion, this highlights the original point behind breaking away from systemd code. What you describe is essentially that systemd being required is a fait accompli.

As I understand the opentmpfiles race condition, it is a failure of the systemd design, not opentmpfiles. systemd being the 1,000lb gorilla, wasn't going to change. And that reinforces the tension with those who objectively don't want to use systemd.

The group of people who don't want to use systemd and who are capable of contributing to such a project seems to be non-cohesive in that they don't or won't contribute to such a project. That in turn seems to increase or at least not sufficiently decrease the friction required to maintain the non-systemd option. I have no idea how much easier systemd-utils will be for Gentoo devs to maintain, but does the effort become trivial, or only a small percentage change? Is it a big short-term gain that only later will seem like not enough?

I'm only somewhat surprised that it is still possible to not use systemd, but I wonder how long that will remain true.

[NeddySeagoon]

lumaro,

eudev is under new management. Join that project instead of doing you own thing.

[Hu]

In my opinion, this highlights the original point behind breaking away from systemd code. What you describe is essentially that systemd being required is a fait accompli.

Unless upstream projects can be convinced to stop depending on systemd's features, yes. More generally, that has been a recurring problem. systemd adds some feature, possibly poorly thought out, but clearly attractive, and other projects proceed to add a hard dependency on it. systemd then becomes just a bit harder to avoid, because there is yet another project that you must either give up, patch, or accept reduced functionality in.

As I understand the opentmpfiles race condition, it is a failure of the systemd design, not opentmpfiles.

Correct. However, allegedly, systemd-tmpfiles, being written in C, is capable of circumventing the problem created by the original bad design. However, while the race condition was a central argument for removing opentmpfiles, the other and larger problem is that systemd keeps extending the tmpfiles format, and upstream projects keep adding uses of those extensions. Even if opentmpfiles were secure (or the administrator did not care about the security issue), it would still need ongoing maintenance to accommodate projects that keep adding dependencies on newer and newer systemd features. Alternately, it would still need a lobbyist to pressure upstream projects to stop adding dependencies on features that opentmpfiles lacks.

The group of people who don't want to use systemd and who are capable of contributing to such a project seems to be non-cohesive in that they don't or won't contribute to such a project.

Agreed.

I have no idea how much easier systemd-utils will be for Gentoo devs to maintain, but does the effort become trivial, or only a small percentage change? Is it a big short-term gain that only later will seem like not enough?

Easier compared to giving up and forcing systemd on everyone? I expect it is appreciably easier, or the latter would have already happened. While I cannot name names, I believe there are at least some Gentoo developers who want not to use systemd on their systems, and who therefore have a personal interest in systemd-utils working when the init system is not systemd.

I'm only somewhat surprised that it is still possible to not use systemd, but I wonder how long that will remain true.

That depends entirely on how long the programs you want to update continue to work without it. I expect that in most cases, Gentoo maintainers will not have the resources to routinely patch out hard dependencies on systemd, so the question devolves to which upstream projects are committed to working on a systemd-free system versus which ones will rush to embrace every systemd feature as it comes out.

[pjp]

Easier compared to giving up and forcing systemd on everyone? I expect it is appreciably easier, or the latter would have already happened. While I cannot name names, I believe there are at least some Gentoo developers who want not to use systemd on their systems, and who therefore have a personal interest in systemd-utils working when the init system is not systemd.

That's a good point too, and I've either seen some mention it, or perhaps similar comments that such Gentoo devs do exist. By easier, I meant maintaining the new systemd-utils compared to maintaining its previous components separately (I have no problem with the new package). I understand that it doesn't take much saving of effort to make it worth doing. But if nothing else were to change, would that savings seem as notable to the individual developers 6 months from now, or will the new package start to seem like too much effort. Did the effort get reduced to ~1/3, 1/2, or only by a tenth of the effort to maintain the 3 packages?

That depends entirely on how long the programs you want to update continue to work without it. I expect that in most cases, Gentoo maintainers will not have the resources to routinely patch out hard dependencies on systemd, so the question devolves to which upstream projects are committed to working on a systemd-free system versus which ones will rush to embrace every systemd feature as it comes out.

Which seems closer to getting out of the way of said 1,000lb gorilla more than anything else. I guess it benefits "web scale" and other large corporate entities sufficiently to force it as I've yet to see any advantage (quite the opposite).

[mv]

By easier, I meant maintaining the new systemd-utils compared to maintaining its previous components separately

Generally speaking, it is always a good idea for packages with a common source/build system to have also only one ebuild instead of splitting it up, unless these ebuilds block each other.

Details depends on upstream. It might even be close to impossible to maintain it in separate ebuilds: Namely if the ebuilds install a common shared library. (Which of the separate ebuild should install the library, and how to avoid collision? Moreover, if the shared library depends on other use flags like acl, you must make sure that all of the other ebuilds are installed with same useflag-setting - both is hard to achieve with dependency trickery and not nice for the user).
If the packages compile a common library in, a shared package saves compiling this libraries several times for each package on the user systems.

[sam_]

By easier, I meant maintaining the new systemd-utils compared to maintaining its previous components separately

Generally speaking, it is always a good idea for packages with a common source/build system to have also only one ebuild instead of splitting it up, unless these ebuilds block each other.

Details depends on upstream. It might even be close to impossible to maintain it in separate ebuilds: Namely if the ebuilds install a common shared library. (Which of the separate ebuild should install the library, and how to avoid collision? Moreover, if the shared library depends on other use flags like acl, you must make sure that all of the other ebuilds are installed with same useflag-setting - both is hard to achieve with dependency trickery and not nice for the user).
If the packages compile a common library in, a shared package saves compiling this libraries several times for each package on the user systems.

Absolutely. FWIW, part of the issue with the split packages was also having to patch e.g. new linux-header changes in 3/4 separate places every time. It got old and when we already have to juggle quite a lot, things which make more sense as well as reducing work look rather attractive.

But don't mistake us taking some convenience where no harm is done for somehow being willing to just drop OpenRC one day because it's easier. It's a different story entirely and it won't happen. (But if you want to make extra extra sure it won't happen, help welcome for OpenRC development itself, as well as improving init scripts! )

[NeddySeagoon]

Does Gentoo focus currently more on systemd?

Gentoo does not focus at all. Gentoo follows $UPSTREAM.

I think that's been said several times in this topic already but quite so concisely.

[pjp]

But don't mistake us taking some convenience where no harm is done for somehow being willing to just drop OpenRC one day because it's easier. It's a different story entirely and it won't happen. (But if you want to make extra extra sure it won't happen, help welcome for OpenRC development itself, as well as improving init scripts! :D)

Only to clarify, I wasn't being "judgy" or anything like that. I was poorly trying to express a curiosity. Ultimately i am concerned for a time when it becomes too much work, but it was not my intent to imply that systemd-utils was an indicator of that happening sooner than later.

Skimming over the OpenRC bugs, I'm not seeing any low hanging fruit

[sam_]

But don't mistake us taking some convenience where no harm is done for somehow being willing to just drop OpenRC one day because it's easier. It's a different story entirely and it won't happen. (But if you want to make extra extra sure it won't happen, help welcome for OpenRC development itself, as well as improving init scripts! )

Only to clarify, I wasn't being "judgy" or anything like that. I was poorly trying to express a curiosity. Ultimately i am concerned for a time when it becomes too much work, but it was not my intent to imply that systemd-utils was an indicator of that happening sooner than later.

Skimming over the OpenRC bugs, I'm not seeing any low hanging fruit

I figured as much, but I wanted to be clear too, just in case anybody was worried about that. I think there's a lot of interest and motivation to keep OpenRC a viable option. I don't envisage it ever becoming too much work, especially as things are far more settled now. But I can understand expressing the concern. Plus, overall, the speed of upstream adopting invasive stuff like logind has slowed, thankfully. There's also alternatives like seatd now.

As for helping w/ OpenRC, there's a few options:

• William has expressed to me a few times that he'd really appreciate help with triaging the bugs on Bugzilla (search). A lot of them may be obsolete, but not all of them, and it'd be really helpful to figure out which (this, in itself, is useful, but may wish to figure out if some have patches we can use, or write some yourself, etc).
• Ditto applies to the github issues but this has less of a staleness problem.
• Searching for "init script" on Bugzilla reveals a fair number of bugs/improvement requests for packages themselves.
• Another search for "OpenRC" in the packages section (not for bugs in OpenRC itself) reveals some more possible init script issues where the bug summary doesn't actually mention "init script"

[ndk]

Long time lurker, first time poster...

@K_Brown
Thank you! When I was looking at that CVE, I was in awe...
A "security risk" by providing a config that could only be supplied by root? Does the CVE author even understand how security works?
Looks like a convenient excuse to drop the support of the tool altogether.

To the "maintainers": Ebuilds with tmpfiles that introduce security vulnerabilities? Seriously? You really make me worry about what's installed on my machine...
If there is no good way to do scans on packages/ebuilds for security risks (with policies that you can define), what stops anyone from creating ebuilds with K3wlSpywareZ and submitting them?
All one needs to do is to volunteer to be maintainer of one of more popular packages and get themselves a nice botnet.

To all 'systemd'-sympathizers: no one forces YOU to NOT use systemd, please extend the courtesy and allow people to have a choice for gods sake. So please stop posting how 'systemd is great' or 'systemd is widely spread', no one asked.

PS. I've been using Gentoo since early 2000s and was generally happy with it. I survived few complete system breakdowns after upgrades. I survived not-so smooth process of moving to multilib. I'm afraid I'm not going to survive this.
I genuinely hope that opentmpfiles comes back to life in the next few weeks. Otherwise I will have to spend my weekend get the heck out of this mess by dropping this so-called 'you have a choice' distro. Apparently, I no longer have any...
I already compromised by installing systemd-tmpfiles. I'm not bringing systemd-utils on my system because someone failed at automating release processes for separate packages and decided to bundle that "lovely" systemd utility in one ebuild and forcing it on everyone.

Good luck...

[sam_]

Long time lurker, first time poster...

@K_Brown
Thank you! When I was looking at that CVE, I was in awe...
A "security risk" by providing a config that could only be supplied by root? Does the CVE author even understand how security works?
Looks like a convenient excuse to drop the support of the tool altogether.

To the "maintainers": Ebuilds with tmpfiles that introduce security vulnerabilities? Seriously? You really make me worry about what's installed on my machine...
If there is no good way to do scans on packages/ebuilds for security risks (with policies that you can define), what stops anyone from creating ebuilds with K3wlSpywareZ and submitting them?
All one needs to do is to volunteer to be maintainer of one of more popular packages and get themselves a nice botnet.

To all 'systemd'-sympathizers: no one forces YOU to NOT use systemd, please extend the courtesy and allow people to have a choice for gods sake. So please stop posting how 'systemd is great' or 'systemd is widely spread', no one asked.

PS. I've been using Gentoo since early 2000s and was generally happy with it. I survived few complete system breakdowns after upgrades. I survived not-so smooth process of moving to multilib. I'm afraid I'm not going to survive this.
I genuinely hope that opentmpfiles comes back to life in the next few weeks. Otherwise I will have to spend my weekend get the heck out of this mess by dropping this so-called 'you have a choice' distro. Apparently, I no longer have any...
I already compromised by installing systemd-tmpfiles. I'm not bringing systemd-utils on my system because someone failed at automating release processes for separate packages and decided to bundle that "lovely" systemd utility in one ebuild and forcing it on everyone.

Good luck...

Your other points have been addressed in this thread extensively. As for systemd-utils, you're free to turn off every single USE flag apart from tmpfiles, which would make it identical to systemd-tmpfiles.

[asturm]

Right. If you want to participate in threads, read them in full. This rehashing of trivialities is a waste of everyone's time.

[NeddySeagoon]

ndk,

Welcome.

You really do have a choice. Gentoo follows upstream. Its quite passible to swim against that stream.
openrc-17.0 works here. I still have a static /dev and absolutely no autoblackmagic.

The price you pay for swimming against the stream is that some things won't build at all.
Some things build (with the ebuilds tweaked) and have reduced, for some users, functionality.

I have a very usable MATE desktop though.

[ndk]

Your other points have been addressed in this thread extensively. As for systemd-utils, you're free to turn off every single USE flag apart from tmpfiles, which would make it identical to systemd-tmpfiles.

Why I am not surprised by your answer? I'm not asking what should I do, so don't give me your unsolicited advice. I've been using this distro longer than you are. I remember when people cared about other people's preferences...

Right. If you want to participate in threads, read them in full. This rehashing of trivialities is a waste of everyone's time.

One more cutie... Assuming for others. Thanks.


Gosh, where did Gentoo go wrong and some of its developers became so fragile and being unable to take a different viewpoint...

[asturm]

You're not inside Gentoo Chat, but you are helping sending this thread directly in there. Maybe it should have been moved there from the get-go, as its fate was already decided by the title.

Check this subforum's description: "Still need help with Gentoo, and your question doesn't fit in the above forums? Here is your last bastion of hope."

[ndk]

You're not inside Gentoo Chat, but you are helping sending this thread directly in there.

Check this subforum's description: "Still need help with Gentoo, and your question doesn't fit in the above forums? Here is your last bastion of hope."

Look at this cutie. Check your messages in this thread before pointing at others.


For the topic: The answer is "not yet, but speeding there"... I will not be surprised in a few months that the systemd-camp prevails and OpenRC and the rest will be abandoned for sake of 'easy to maintain', i.e. 'not my problem'.

[sam_]

For the topic: The answer is "not yet, but speeding there"... I will not be surprised in a few months that the systemd-camp prevails and OpenRC and the rest will be abandoned for sake of 'easy to maintain', i.e. 'not my problem'.

And yet within the last few posts, I already made clear that it won't happen. Crazy.

[ndk]

For the topic: The answer is "not yet, but speeding there"... I will not be surprised in a few months that the systemd-camp prevails and OpenRC and the rest will be abandoned for sake of 'easy to maintain', i.e. 'not my problem'.

And yet within the last few posts, I already made clear that it won't happen. Crazy.

I don't think that some current gentoo developers have a track record to point to. What you see is what you get. and I see a slow-creep up of systemd-"stuff" into mainstream Gentoo. Whatever promises you make have no meaning.
The only reason why eudev still exists outside systemd is because it was picked up after Gentoo devs effectively abandoned it. The same with opentmpfiles. The only reason why there is still a chance of opentmpfiles getting back is because of @K_Brown (thank you!). I also read between lines... Like here: https://github.com/OpenRC/opentmpfiles/ ... -996131106
So, please spare me with your fanfare...