Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 12:31:25 +0200 Michał Górny wrote: > On Sun, 26 May 2013 12:12:49 +0200 > Robert David wrote: > > > On Sun, 26 May 2013 05:49:48 -0400 > > Rich Freeman wrote: > > > > > On Sun, May 26, 2013 at 4:32 AM, Ben de Groot > > > wrote: > > > > On 26 May 2013 15:37, Michał Górny wrote: > > > >> > > > >> Considering the design of OpenRC itself, it wouldn't be *that > > > >> hard*. Actually, a method similar to one used in oldnet would > > > >> simply work. That is, symlinking init.d files to a common > > > >> 'systemd-wrapper' executable which would parse the unit files. > > > > > > > > I think this idea actually makes sense. Re-using upstream work > > > > seems a logical idea, and could ease maintenance. Of course the > > > > issue is whether the OpenRC devs see any benefit in this. > > > > > > Init.d scripts are just shell scripts. All somebody needs to do > > > is write a shell script that parses a unit file and does what it > > > says, and exports an openrc-oriented init.d environment. That > > > can be packaged separately, or whatever, and maybe an eclass > > > could make it easy to install (point it at the upstream/filesdir > > > unit and tell it what to call the init.d script, and you get the > > > appropriate symlink/script). > > > > > > The OpenRC devs don't have to endorse anything - sure it would > > > make sense to bundle it, but it could just as easily be pulled in > > > as a dep or used manually by a user. > > > > > > The script could ignore any unit features that aren't implemented. > > > You can ignore settings like auto-restart/inetd and just use the > > > settings that get the daemon started. > > > > +1 > > > > I would rather add shell script to parse unit and generate > > appropriate init script while building than have initscript wrapper > > that will call and parse on execution. As you said, some eclass. > > This effectively duplicates data for no real benefit. > > 1) we waste disk space. Come on, it is 2013, wasting few inodes. I did not got these problems in the old good times with my 386 with 4mb ram and few MB hdd. Those with embedded system will mask many other files, not only systemd units (so they save one inode more with my approach, when need no initscript-wrapper). Users of regular server/desktops/laptops, 10-20 inodes more? They would rather won't use Gentoo with its portage tree or do not compile kernel sources, etc. > > 2) if user modifies init.d script, systemd unit is out-of-sync. > And the init.d is rewritten (potentially with CONFIG_PROTECT) on next > upgrade. If someone update iniscript, must be prepared to be outofsync with package version. Thus CONFIG_PROTECT. > > 3) if user modifies systemd unit, init.d script is out-of-sync. > Why someone will modify systemd unit when will be using init.d scripts. And for those few people doing this, the same script as portage use for converting can be used. Robert.
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, May 26, 2013 at 6:31 AM, Michał Górny wrote: > On Sun, 26 May 2013 12:12:49 +0200 > Robert David wrote: > >> On Sun, 26 May 2013 05:49:48 -0400 >> Rich Freeman wrote: >> >> > Init.d scripts are just shell scripts. All somebody needs to do is >> > write a shell script that parses a unit file and does what it says, >> > and exports an openrc-oriented init.d environment. That can be >> > packaged separately, or whatever, and maybe an eclass could make it >> > easy to install (point it at the upstream/filesdir unit and tell it >> > what to call the init.d script, and you get the appropriate >> > symlink/script). >> > >> >> I would rather add shell script to parse unit and generate appropriate >> init script while building than have initscript wrapper that will call >> and parse on execution. As you said, some eclass. > > This effectively duplicates data for no real benefit. > > 2) if user modifies init.d script, systemd unit is out-of-sync. > And the init.d is rewritten (potentially with CONFIG_PROTECT) on next > upgrade. > > 3) if user modifies systemd unit, init.d script is out-of-sync. > To clarify, I was agreeing with the use of a wrapper script - likely symlinked. It would not be compiled/generated at install time, beyond creating the symlink and maybe a conf.d file that pointed to the unit. The eclass would just streamline the installation. As you point out that keeps the configs always in-sync. It also means that if the wrapper script is upgraded to add new features all packages benefit, without needing a re-install. Rich
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 12:12:49 +0200 Robert David wrote: > On Sun, 26 May 2013 05:49:48 -0400 > Rich Freeman wrote: > > > On Sun, May 26, 2013 at 4:32 AM, Ben de Groot > > wrote: > > > On 26 May 2013 15:37, Michał Górny wrote: > > >> > > >> Considering the design of OpenRC itself, it wouldn't be *that > > >> hard*. Actually, a method similar to one used in oldnet would > > >> simply work. That is, symlinking init.d files to a common > > >> 'systemd-wrapper' executable which would parse the unit files. > > > > > > I think this idea actually makes sense. Re-using upstream work > > > seems a logical idea, and could ease maintenance. Of course the > > > issue is whether the OpenRC devs see any benefit in this. > > > > Init.d scripts are just shell scripts. All somebody needs to do is > > write a shell script that parses a unit file and does what it says, > > and exports an openrc-oriented init.d environment. That can be > > packaged separately, or whatever, and maybe an eclass could make it > > easy to install (point it at the upstream/filesdir unit and tell it > > what to call the init.d script, and you get the appropriate > > symlink/script). > > > > The OpenRC devs don't have to endorse anything - sure it would make > > sense to bundle it, but it could just as easily be pulled in as a dep > > or used manually by a user. > > > > The script could ignore any unit features that aren't implemented. > > You can ignore settings like auto-restart/inetd and just use the > > settings that get the daemon started. > > +1 > > I would rather add shell script to parse unit and generate appropriate > init script while building than have initscript wrapper that will call > and parse on execution. As you said, some eclass. This effectively duplicates data for no real benefit. 1) we waste disk space. 2) if user modifies init.d script, systemd unit is out-of-sync. And the init.d is rewritten (potentially with CONFIG_PROTECT) on next upgrade. 3) if user modifies systemd unit, init.d script is out-of-sync. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 05:49:48 -0400 Rich Freeman wrote: > On Sun, May 26, 2013 at 4:32 AM, Ben de Groot > wrote: > > On 26 May 2013 15:37, Michał Górny wrote: > >> > >> Considering the design of OpenRC itself, it wouldn't be *that > >> hard*. Actually, a method similar to one used in oldnet would > >> simply work. That is, symlinking init.d files to a common > >> 'systemd-wrapper' executable which would parse the unit files. > > > > I think this idea actually makes sense. Re-using upstream work > > seems a logical idea, and could ease maintenance. Of course the > > issue is whether the OpenRC devs see any benefit in this. > > Init.d scripts are just shell scripts. All somebody needs to do is > write a shell script that parses a unit file and does what it says, > and exports an openrc-oriented init.d environment. That can be > packaged separately, or whatever, and maybe an eclass could make it > easy to install (point it at the upstream/filesdir unit and tell it > what to call the init.d script, and you get the appropriate > symlink/script). > > The OpenRC devs don't have to endorse anything - sure it would make > sense to bundle it, but it could just as easily be pulled in as a dep > or used manually by a user. > > The script could ignore any unit features that aren't implemented. > You can ignore settings like auto-restart/inetd and just use the > settings that get the daemon started. > > Rich > +1 I would rather add shell script to parse unit and generate appropriate init script while building than have initscript wrapper that will call and parse on execution. As you said, some eclass. Robert.
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, May 26, 2013 at 4:32 AM, Ben de Groot wrote: > On 26 May 2013 15:37, Michał Górny wrote: >> >> Considering the design of OpenRC itself, it wouldn't be *that hard*. >> Actually, a method similar to one used in oldnet would simply work. >> That is, symlinking init.d files to a common 'systemd-wrapper' >> executable which would parse the unit files. > > I think this idea actually makes sense. Re-using upstream work seems a > logical idea, and could ease maintenance. Of course the issue is > whether the OpenRC devs see any benefit in this. Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). The OpenRC devs don't have to endorse anything - sure it would make sense to bundle it, but it could just as easily be pulled in as a dep or used manually by a user. The script could ignore any unit features that aren't implemented. You can ignore settings like auto-restart/inetd and just use the settings that get the daemon started. Rich
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On 26 May 2013 15:37, Michał Górny wrote: > On Sun, 26 May 2013 00:14:36 +0800 > Ben de Groot wrote: > >> Systemd is diametrically opposed to the FreeBSD, customization, >> extreme configurability, and top-notch developer community aspects of >> that. Systemd upstream developers have made it abundantly clear they >> are not interested in working with Gentoo developers to see to the >> needs of source-based distros. They stand for vertical integration >> instead of customization and configurability. >> >> And you misunderstood: it is systemd that is aggressively opposed to >> Gentoo. But apparently that doesn't bother some of our developers and >> Gentoo is becoming more and more welcoming to it. > > By the way, we should really keep the separation between systemd itself > and the unit files. I agree that systemd is not the best thing we could > have. But the unit file format is, er, good enough -- and has > the advantage of eventually taking a lot of work from our shoulders. > > Although some of the ideas (esp. wrt targets) are near to crazy > and awfully hard to understand, that's what we have and trying to do > something else is eventually going to make people's lives harder. > > We should *really* work on supporting the unit files within OpenRC > (aside to init.d files). That's a way to at least: > > a) reuse the work that has been done upstream already (when it was > done), > > b) have common service names and startup behavior in all relevant > distros (which is really beneficial to the users). > > Considering the design of OpenRC itself, it wouldn't be *that hard*. > Actually, a method similar to one used in oldnet would simply work. > That is, symlinking init.d files to a common 'systemd-wrapper' > executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. > On the completely different topic, I agree that systemd design is far > from the best and the way it's maintained is just bad. I was interested > in the past in creating an improved alternative using compatible file > format and libraries, while choosing a better design, improving > portability and keeping stuff less integrated. > > But the fact is -- I doubt it will make sense, much like the eudev > project. And it will take much more work, and give much less > appreciation. > > First of all, working on it will require a lot of work. Seeing how > large systemd become and how rapidly it is developing, establishing > a good alternative (even dropping such useless parts as the Journal) > will take at least twice that work. > > Then, it will require people working on it. People who know the details > of various systems and who are willing to spend their time on it. > And there wouldn't be much of people really willing to work on it. > > The systemd haters will refuse the project because of its resemblance > to systemd. The systemd lovers will refuse it because of its > resemblance to systemd. And the OpenRC lovers will want to design it > to resemble OpenRC which is just pointless. Then the few remaining > people will find systemd 'good enough'. > > And even if there are a few people who will want to work on it, > and design a 'good systemd', they wouldn't get much appreciation. > Fedora definitely won't care for it. It would have to be really > definitely awesome for most Linux distros to even notice it. > And I doubt *BSD people would be interested in something external. > > It is possible that systemd upstream will steal a few patches or ideas > from it. Yet they will never apply any of the really important changes, > so the project will have to be maintained indefinitely. The only hope > for it would be to win over systemd users which I doubt will happen. > > So there's a lot of work, no fame or money in it, and most likely more > work being the only future. Anyone volunteering? I agree it would be pretty hard to carve out a niche for this. Personally I would see more in runit. -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 00:14:36 +0800 Ben de Groot wrote: > Systemd is diametrically opposed to the FreeBSD, customization, > extreme configurability, and top-notch developer community aspects of > that. Systemd upstream developers have made it abundantly clear they > are not interested in working with Gentoo developers to see to the > needs of source-based distros. They stand for vertical integration > instead of customization and configurability. > > And you misunderstood: it is systemd that is aggressively opposed to > Gentoo. But apparently that doesn't bother some of our developers and > Gentoo is becoming more and more welcoming to it. By the way, we should really keep the separation between systemd itself and the unit files. I agree that systemd is not the best thing we could have. But the unit file format is, er, good enough -- and has the advantage of eventually taking a lot of work from our shoulders. Although some of the ideas (esp. wrt targets) are near to crazy and awfully hard to understand, that's what we have and trying to do something else is eventually going to make people's lives harder. We should *really* work on supporting the unit files within OpenRC (aside to init.d files). That's a way to at least: a) reuse the work that has been done upstream already (when it was done), b) have common service names and startup behavior in all relevant distros (which is really beneficial to the users). Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. On the completely different topic, I agree that systemd design is far from the best and the way it's maintained is just bad. I was interested in the past in creating an improved alternative using compatible file format and libraries, while choosing a better design, improving portability and keeping stuff less integrated. But the fact is -- I doubt it will make sense, much like the eudev project. And it will take much more work, and give much less appreciation. First of all, working on it will require a lot of work. Seeing how large systemd become and how rapidly it is developing, establishing a good alternative (even dropping such useless parts as the Journal) will take at least twice that work. Then, it will require people working on it. People who know the details of various systems and who are willing to spend their time on it. And there wouldn't be much of people really willing to work on it. The systemd haters will refuse the project because of its resemblance to systemd. The systemd lovers will refuse it because of its resemblance to systemd. And the OpenRC lovers will want to design it to resemble OpenRC which is just pointless. Then the few remaining people will find systemd 'good enough'. And even if there are a few people who will want to work on it, and design a 'good systemd', they wouldn't get much appreciation. Fedora definitely won't care for it. It would have to be really definitely awesome for most Linux distros to even notice it. And I doubt *BSD people would be interested in something external. It is possible that systemd upstream will steal a few patches or ideas from it. Yet they will never apply any of the really important changes, so the project will have to be maintained indefinitely. The only hope for it would be to win over systemd users which I doubt will happen. So there's a lot of work, no fame or money in it, and most likely more work being the only future. Anyone volunteering? -- Best regards, Michał Górny signature.asc Description: PGP signature
