Draft: testing/systemd: new aport
It builds on amd64 now and only 17 tests fail
It's also possible to boot alpine with it
No need to comment about lint issues, will be fixed later
Merge request reports
Activity
added aports:add label
added status:mr-hold label
- Resolved by Jakub Panek
I think that it is better to move musl-libc support efforts to systemd upstream (if they have any interest on this). Otherwise this port will be not easy to maintain.
added 936 commits
-
5bec990e...53b28cf9 - 935 commits from branch
alpine:master
- 7039e42f - testing/systemd: new aport
-
5bec990e...53b28cf9 - 935 commits from branch
If you want a distro with systemd, there are hundreds of those out there.
Sure but why does that matter? Alpine is still not a distro with systemd even if it has systemd packaged and available.
I don't understand why you feel the need to introduce it to Alpine.
Because I can.
We should be looking at the "why" before we look at the "how".
There is no reason to look at "why". Your personal dissent with it shouldn't affect whole Alpine.
There is always a reason to look at "why" when doing engineering, and "because I can" is not justification enough to do something. There are lots of things I could do, but choose not to, because not is the better alternative; and my reaction has nothing to do with my personal dissent and everything to do with Alpine.
Once systemd gets a foot in a distribution, it doesn't stop. The way it works is so unique that people who want to work with it end up patching their daemons pretty soon, to support the systemd features - and oh, since they've done the work, it would be so nice if the distribution could add the option to the packaging scripts. And patch after patch, service after service, systemd leeches developers' time and effort; the ones who are hostile to systemd start doing less and less; the ones who remain active work with systemd, and slowly, without even wanting it, without even realizing it, you now have a systemd distribution, just like the twenty others that came before.
You need to nip the cancer in the bud. Don't package it - it's the only way to be sure.
You want a systemd+musl distribution? Go make your own, nobody's stopping you; just don't involve Alpine resources in this.
from a packager's perspective - introducing systemd doesn't make a lot of sense, since existing packages that provide init scripts already do so in openrc format. so, if we add systemd "just for fun", one of two things would have to happen:
- all packages that have systemd scripts are edited to provide systemctl support, which is a huge effort for something that only a few people are going to use out of morbid curiosity
- the packages would have to be kept as-is, requiring people to get init scripts for all the core components separately. if something updates and the script changes - they're out of luck, since they have to monitor for that all the time.
whichever way you look at it, it's hugely impractical
SysTemD is the STD of operating systems. There is no "one little poke", you can't be a little bit pregnant.
Long story short, SysTemD didn't happen by accident. I am not touching it with a 10 foot pole and if that thing start infesting in Alpine I'll drop Alpine entirely.
My $0.02.
Edited by Alex@ay This is a tasteless comment and we do not appreciate that here. If you don't have anything constructive to say, maybe just say nothing.
How systemd hardcoded DNS server to 8.8.8.8 (Google):
Not hardcoded, linked bug even explains that. I have already changed default DNS servers (which are Cloudflare + Google) and default time servers (Google).
How systemd just one day decided to kill all your processes on log out:
That is also fixed.
added 3 commits
-
011e9d05...e675161b - 2 commits from branch
alpine:master
- bf60e2bf - testing/systemd: new aport
-
011e9d05...e675161b - 2 commits from branch
Why would a TSC decision be required for this to be merged, if it is not replacing openrc as the default init system?
Alpine contains other alternative init systems, and the TSC was not involved in the approval or disapproval of those alternative init systems.
The TSC would only need to make a decision on changing the default init system away from OpenRC.
Edited by Ariadne ConillBecause regardless of whether or not it becomes the default, this could have wide-reaching consequences for Alpine. Virtually every package that includes a daemon would ideally be updated with a -systemd subpackage with the systemd units and any other relevant systemd crap. I don't think anyone should make a decision which could have consequences for hundreds or thousands of packages without a TSC decision.
To be absolutely clear: the TSC has not mandated that package maintainers support any of the other alternative init systems.
I do not see why we would mandate that package maintainers support systemd. We certainly won't make a decision on systemd outside the scope changing the default.
From past discussions on the alternative init system topic, while individual opinions vary on the quality of proposed alternative init systems, the TSC believes it is important to allow contributors to experiment with alternative init systems, and has no interest in impeding that, be it s6-rc, systemd, or some other init system.
So we have no interest in making a decision on this (unless the proposal is to change the default init, but systemd is not likely to be selected by the TSC given the attitude of upstream).
It is a summary of the current discussion that has happened amongst the TSC members. If there is an actual matter for the TSC to discuss, it most certainly is not the inclusion or non-inclusion of an alternative init system in testing repository, unless the maintainer of that init system has specific requests that require the TSC to handle.
If you have a technical argument for why this falls under the scope of the TSC, you may open a work item with the TSC.
The Alpine Linux Technical Steering Committee (TSC) is responsible for
approving changes that either
- have a significant impact to Alpine Linux users
- affect a number of packages, or
- are potentially controversial
Check, check, and check.
Edited by Drew DeVaulthave a significant impact to Alpine Linux users
a random init in testing does not meet this. yes, we have quite the bikeshed about this right here in this thread, and we could open the exact same bikeshed about community/runit as well, which is already there. strangely, nobody has, because nobody really cares.
affect a number of packages
ok, easily solved: no explicit systemd support will be added to any existing package (also in testing). done.
are potentially controversial
this is the only one that is met. and ONLY because it is 'systemd', and no other reason
Still speaking with my TSC hat on, discussion and review of aports issues do not typically involve invoking the Alpine TSC as a political prop.
If you believe there is an issue of merit for the Alpine TSC to make a decision about you may open a work item about that issue. I will even ensure it is prioritized for Thursday's meeting.
Speaking in personal capacity: I don't think that Alpine will adopt systemd, even if somebody wishes to experiment with it. We should have a community where experimentation is encouraged with abandon.
I'm not going to file a TSC work item, at least not yet. But I am going to call for good faith discussion.
Review of aports issues do not typically involve invoking the Alpine TSC as a political prop.
Assume that those presenting concerns here are doing so in good faith and have a genuine belief that this may fall under the purview of the TSC mandate. systemd is, if nothing else, a good test of our ability to discuss controversial issues that affect Alpine. Doing so requires everyone to participate in earnest.
If a defensible argument can be made that this change would fall under the TSC mandate then the TSC is a useful tool working as designed, not a "political prop".
Edited by Drew DeVaultSpeaking with my TSC hat on again:
In a previous message, you declared that the TSC must make a decision on whether this package is accepted.
If you have technical merits to debate in this merge request, feel free to do so, but unilaterally declaring that the TSC must make a decision in a merge request rather than opening a TSC work item is inappropriate. Please stick to the technical merits, and if necessary, you may open a TSC work item which I will be happy to prioritize for Thursday's meeting.
In a previous message, you declared that the TSC must make a decision on whether this package is accepted.
This is not true. Please re-read my messages. I opened with "surmising" on whether or not a TSC decision was called for, and the ensuing discussion was attempting to prove or refute this premise. The goal has been to determine if opening a work item for the TSC is appropriate here, not to call for a decision by the TSC to be made in this very thread. I don't see any interpretation of my comments as a "unilaterally declaring that the TSC must make a decision in a merge request".
My interpretation was that you were introducing the TSC to this conversation as a way to apply braking energy to the surrounding conversation. If that is not the intent, I am glad to hear it, but please do not invoke the TSC in this way going forward -- if you want the TSC to make a decision on something, open a work item.
With all due respect, I am going to continue to reserve the right to discuss whether or not the TSC's involvement is called for in a given change without necessarily immediately calling for it.
"Braking energy" is not necessarily a bad thing. Change review involves opening threads of discussion and resolving them before applying the change. This necessarily slows the process down, but it is nevertheless is a good thing. Arguments raised in earnest should always be acceptable regardless of whether or not they apply "braking energy". If I had been making bad faith or disruptive arguments, then you would have a point, but I do not think that is the case here.
The reason why we don't do that for s6-rc is that Alpine devs want to have the next version of s6-rc (1.0) as well as a friendlier user interface (s6-frontend) before switching to it. I am working on both these things.
The current version of s6-rc is packaged because it can be used as pure mechanism in situations that do not involve official service management in Alpine packages. The same cannot be said about systemd: it cannot be run independently of the existing init system, so including it necessarily involves systemd-specific policy files in other packages.
Sure would be great to have service files for specific service supervisor, but I'm not going to scream at everyone to add them just because systemd is present (currently only aiming for testing).
I'm trying too achieve much through compat with openrc being sub-supervisor on systemd system (not great option but I'm not that interested into shoving systemd in Alpine). Also it seems that there are some aports which have service files anyway: #12199 (closed)My current goals and what I'm working on are:
- package systemd properly
- have backward compat with openrc
- make systemd boot/work without issues
Edited by Jakub PanekYou don't seem to realize the level of difficulty of running systemd and another service manager independently. Running systemd is not at all like running busybox init instead of sysvinit. It is an integrated init system, and wants to manage everything. In order to "make it boot without issues", you will have to let it handle a certain number of services that openrc currently manages. You will have to make decisions about how and when to launch the device manager, how and when to mount the filesystems, how and when to enable network interfaces, etc. etc.
In other words: you will not be able to separate mechanism from policy; "packaging systemd properly" means turning it into the init system, with limited options for delegating services to openrc. You will not be able to accomplish your goals without involving Alpine developer time and effort, and without significantly reworking the way Alpine works in order to accommodate systemd. And that is what I'm opposed to.