On Sun, 26 May 2013 12:31:25 +0200 Michał Górny <mgo...@gentoo.org> wrote:
> On Sun, 26 May 2013 12:12:49 +0200 > Robert David <robert.david.pub...@gmail.com> wrote: > > > On Sun, 26 May 2013 05:49:48 -0400 > > Rich Freeman <ri...@gentoo.org> wrote: > > > > > On Sun, May 26, 2013 at 4:32 AM, Ben de Groot <yng...@gentoo.org> > > > wrote: > > > > On 26 May 2013 15:37, Michał Górny <mgo...@gentoo.org> 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.
