| Summary: | [Future EAPI] Move initd/confd functions out of PMS | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Michael Orlitzky <mjo> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | esigra, gentoo, mgorny, openrc, sam, zlogene |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
Keep in mind that we must support these functions indefinitely for previous EAPIs. Removing them would actually add more code (and more case distinctions in the spec) instead of simplifying anything. Besides, doinitd and doconfd are both trivial (< 10 lines) bash scripts.
It would be a different story if we didn't have these functions and would consider adding them, but for their removal I don't see much incentive.
> * OpenRC and systemd would be handled consistently.
Why would this be important?
(In reply to Ulrich Müller from comment #1) > Keep in mind that we must support these functions indefinitely for previous > EAPIs. Removing them would actually add more code (and more case > distinctions in the spec) instead of simplifying anything. Besides, doinitd > and doconfd are both trivial (< 10 lines) bash scripts. True, but developers don't have to *think* about them. And while the PMS will never get simpler, some day a long long time from now all of the current EAPIs will be obsolete. > > > * OpenRC and systemd would be handled consistently. > > Why would this be important? It's just one fewer "if" statement for everyone to remember. After: "If I want to install a service script for an init system, I inherit $initsystem.eclass and use the corresponding $initsystem_do* function." Before: "If I want to install a service script for an init system, I inherit $initsystem.eclass and use the corresponding $initsystem_do* function, unless that init system is OpenRC, in which case I use doinitd." (In reply to Michael Orlitzky from comment #2) > After: "If I want to install a service script for an init system, I inherit > $initsystem.eclass and use the corresponding $initsystem_do* function." > > Before: "If I want to install a service script for an init system, I inherit > $initsystem.eclass and use the corresponding $initsystem_do* function, > unless that init system is OpenRC, in which case I use doinitd." Nobody will stop you from proposing an openrc.eclass, with two lines (plus usual comments and padding): openrc_doinitd() { doinitd "$@"; } openrc_doconfd() { doconfd "$@"; } No package manager changes required. :-D (In reply to Michael Orlitzky from comment #2) > (In reply to Ulrich Müller from comment #1) > > Keep in mind that we must support these functions indefinitely for previous > > EAPIs. Removing them would actually add more code (and more case > > distinctions in the spec) instead of simplifying anything. Besides, doinitd > > and doconfd are both trivial (< 10 lines) bash scripts. > > True, but developers don't have to *think* about them. And while the PMS > will never get simpler, some day a long long time from now all of the > current EAPIs will be obsolete. We need to wait a long long time from now to take the action in this proposal. I think there is a major difference in semantic between OpenRC and systemd. One of the selling points of systemd was that units would be shipped and installed by upstream packages, and therefore shared between multiple distros. Technically speaking, systemd.eclass is only necessary for packages that don't follow this semantic or when we want to customize stuff. OpenRC follows the older semantic where distros ship init.d files and nobody cares about cross-distro compatibility. While technically OpenRC was supposed to be cross-platform, the idea really never caught before. In fact, the primary idea behind OpenRC was to share it with NetBSD -- but NetBSD never switched to OpenRC. Today, the situation is a bit different but not different enough, at least right now. Most of OpenRC init.d scripts are still installed by ebuilds. In my opinion, keeping doinitd and doconfd in PMS makes sense because they are much more commonly used than the systemd counterparts -- and that's pretty much by design. At least for as long as Gentoo supports OpenRC. Once OpenRC becomes some half-dead barely supported init system, we can discuss removing doinitd/doconfd. Today only the first part is true. Adding systemd functions to PMS makes little sense because most of the time they are not actually needed in ebuilds. And again, that's by design. Besides, systemd has more functions than OpenRC and it's still in active development, so we'd either have to add more than 2 functions (and they would probably be more complex than OpenRC ones) and possible expect more in the future, or support systemd only partially. This would cause unnecessary confusion. (In reply to Michał Górny from comment #5) > I think there is a major difference in semantic between OpenRC and systemd. > > One of the selling points of systemd was that units would be shipped and > installed by upstream packages, and therefore shared between multiple > distros. Technically speaking, systemd.eclass is only necessary for > packages that don't follow this semantic or when we want to customize stuff. > > OpenRC follows the older semantic where distros ship init.d files and nobody > cares about cross-distro compatibility. While technically OpenRC was > supposed to be cross-platform, the idea really never caught before. In > fact, the primary idea behind OpenRC was to share it with NetBSD -- but > NetBSD never switched to OpenRC. Today, the situation is a bit different > but not different enough, at least right now. Most of OpenRC init.d scripts > are still installed by ebuilds. This is true of OpenRC as well. A "good" service script should consist of a few variable declarations at the top, and maybe a start_pre() or reload() function. The contents of the variables are portable these days, especially if you integrate them with the upstream build system for things like @bindir@ and @libdir@, which is what everyone does for systemd too. When OpenRC was a Gentoo fork, there was little reason to bother. There still aren't many users, but OpenRC strives to be an independent upstream project. There are a few niche distros who use it by default, and a few more who offer it as an option. True, they all ship their own service scripts... but that's only because decent portable ones haven't been upstreamed yet. And the fact that no one has done it is not a good reason not to do it. Regardless, I think it's unnecessarily weird to have one pseudo-independent upstream project's (configurable!) service script directory hard-coded into our package managers. In every other situation where a bunch of packages need to know e.g. where apache's modules live, there's an eclass to handle it. Put it this way: if OpenRC were to relocate its service scripts to /lib/openrc, how silly would it be that our PMS was affected? You could also teach OpenRC to handle .service files and solve the problem once and for all. (In reply to Michał Górny from comment #7) > You could also teach OpenRC to handle .service files and solve the problem > once and for all. That's a great idea! (In reply to Michael Orlitzky from comment #6) > Regardless, I think it's unnecessarily weird to have one pseudo-independent > upstream project's (configurable!) service script directory hard-coded into > our package managers. In every other situation where a bunch of packages > need to know e.g. where apache's modules live, there's an eclass to handle > it. /etc/init.d/ is not specific to OpenRC, but is the location used by SysV init. It was widely used, e.g. in Debian, Redhat, and SuSE. > Put it this way: if OpenRC were to relocate its service scripts to > /lib/openrc, how silly would it be that our PMS was affected? _Then_ would be a good time to think about dropping doinitd etc. Currently these commands just work and they require zero maintenance. So as I said above, I don't see much incentive for their removal at this point. (In reply to Benda Xu from comment #8) > (In reply to Michał Górny from comment #7) > > You could also teach OpenRC to handle .service files and solve the problem > > once and for all. > > That's a great idea! systemd aggressively uses bleeding-edge linux-only features. There's no way to implement all of them (safely) using POSIX interfaces. This is how we got the unfixable security issues with opentmpfiles. |
The doinitd and doconfd functions (and their new* counterparts) date back to a time when OpenRC was the sole init system for Gentoo and when Debian still used an incompatible start-stop-daemon. Now that OpenRC is its own independent project, it's awkward to have its $(sysconfdir)/init.d and $(sysconfdir)/conf.d directories baked into our package manager specification. In a future EAPI, I think we should eliminate these functions from the specification and move them to an eclass akin to systemd.eclass. This helps in the following ways: * OpenRC and systemd would be handled consistently. * We can change the names of the OpenRC functions to avoid referring explicitly to the names of the directories, which are an implementation detail. Something like openrc_doservice() would be an improvement over doinitd(). * When a package's OpenRC service scripts are upstreamed (as they should be), we can avoid inheriting the new eclass, reducing the total amount of code involved. This has the added benefit of being easy to implement, both in the PMS/eclass and for developers in their ebuilds.