Skip to content
Snippets Groups Projects

Draft: testing/systemd: new aport

Closed Jakub Panek requested to merge pj/aports:systemd into master

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

Edited by Jakub Panek

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • added aports:add label

  • Jakub Panek changed the description

    changed the description

  • Jakub Panek added 1 commit

    added 1 commit

    Compare with previous version

  • Jakub Panek added 1 commit

    added 1 commit

    Compare with previous version

  • Jakub Panek added 1 commit

    added 1 commit

    Compare with previous version

    • Contributor
      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.

  • Jakub Panek resolved all threads

    resolved all threads

  • Jakub Panek added 936 commits

    added 936 commits

    Compare with previous version

  • Jakub Panek added 1 commit

    added 1 commit

    Compare with previous version

  • Jakub Panek added 1 commit

    added 1 commit

    Compare with previous version

    • If you want a distro with systemd, there are hundreds of those out there. I don't understand why you feel the need to introduce it to Alpine. We should be looking at the "why" before we look at the "how".

    • Author Contributor

      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

    • option 3: systemd-openrc-generator. i don't think it's a very good idea, because 1) unlike sysv script dependencies, openrc scripts are turing-complete, and 2) openrc script dependencies are frequently broken to begin with (rc_parallel is considered usually broken).

    • Contributor

      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
    • Nice to see that this conversation has devolved to comparisons to STIs.

    • @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.

    • Author Contributor

      How systemd hardcoded DNS server to 8.8.8.8 (Google):

      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658

      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:

      https://linux.slashdot.org/story/16/05/29/212204/systemd-starts-killing-your-background-processes-by-default

      That is also fixed.

    • Please register or sign in to reply
    • Contributor

      Regardless Alpine Linux in particular, I think that a musl-libc and systemd based mainstream distro can exist. Since Alpine is the mainstream musl-libc distro, there isn't too much option for developers in order to test their work.

    • Gentoo has both a musl overlay and systemd packaged, might be an option to look into beautifying their musl ecosystem because God knows it's in need of it

    • Please register or sign in to reply
  • Jakub Panek added 3 commits

    added 3 commits

    Compare with previous version

  • I don't like this, but I don't want to discourage you from working on it if you find it important. However, I will generally surmise that a TSC decision would be called for before this can be merged.

  • 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 Conill
    • Because 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).

    • Is that Ariadne Conill speaking or the TSC speaking?

    • 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 DeVault
    • A package in testing:

      • does not have significant impact to Alpine Linux users,
      • does not affect a number of packages,
      • and in this case is only controversial because of the package name.
    • Contributor

      have 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

    • Contributor

      if you have a response that is not going to be formally opening a tsc work item, then perhaps it is best left unsent, instead of endlessly arguing about it in this thread.

    • Knock it off. We have every right to discuss the merits of any change to aports. You can open a CoC work item if you think otherwise.

    • 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 DeVault
    • Speaking 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.

    • Please register or sign in to reply
    • Author Contributor

      We don't do that for s6-rc so I don't see why that would be an issue for systemd.

    • 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.

    • Please register or sign in to reply
  • What is your goal if not a system whose services are managed by systemd? I can't imagine it's all that useful to just get booted to a shell with systemd and :tada:

    • Author Contributor

      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 Panek
    • You 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.

    • Please register or sign in to reply
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
Please register or sign in to reply
Loading