From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D6F721381F3 for ; Sun, 26 May 2013 10:58:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6871CE0C7F; Sun, 26 May 2013 10:57:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 631F7E0C73 for ; Sun, 26 May 2013 10:57:31 +0000 (UTC) Received: from localhost (178-37-163-206.adsl.inetia.pl [178.37.163.206]) (using SSLv3 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 52A8133DF07; Sun, 26 May 2013 10:57:29 +0000 (UTC) Date: Sun, 26 May 2013 12:31:25 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: gentoo-dev@lists.gentoo.org Cc: robert.david.public@gmail.com, rich0@gentoo.org Subject: Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697)) Message-ID: <20130526123125.2d0f7836@gentoo.org> In-Reply-To: <20130526121249.49e00ce7@gmail.com> References: <20130526093755.42b62259@gentoo.org> <20130526121249.49e00ce7@gmail.com> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.18; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/0/QhloKmOsTJCYBxIpGG1vv"; protocol="application/pgp-signature" X-Archives-Salt: 9a71de39-2b05-49be-842d-550404e59248 X-Archives-Hash: 60d39e418449a35c4981f3da0daacbf6 --Sig_/0/QhloKmOsTJCYBxIpGG1vv Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On Sun, 26 May 2013 12:12:49 +0200 Robert David wrote: > On Sun, 26 May 2013 05:49:48 -0400 > Rich Freeman wrote: >=20 > > On Sun, May 26, 2013 at 4:32 AM, Ben de Groot > > wrote: > > > On 26 May 2013 15:37, Micha=B3 G=F3rny 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. > >=20 > > 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). > >=20 > > 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. > >=20 > > 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 >=20 > 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. --=20 Best regards, Micha=B3 G=F3rny --Sig_/0/QhloKmOsTJCYBxIpGG1vv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJRoeR+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKaPsP/A4yXO2xYuayqzUvu039NIpS xvNW0kSuLTqYun+0nYkRxK6kC2nv5jGZd0pkO4gtUv3QhdZ+XkIEJFpNpTT5372Q ygSN6xjqtiR64RQy6t2HnKeLRCc3Uq+AHNBXVjCPsTjyeVc4E+DxScbYbmisPi/H EF2pLTx1Hcbhp8f6SVHk3HXOcz9Rc4MgcqIjD3A/idLq3db/WCtEpNaluzARjpoX QD1keY19HBnLEBs1qNTxkt0ZGE2bBSih/Ggz3uY71YGqbNluyUyQhlwO2eCsDEOp eQOUWibI9kK79ZXTbcwX4A6DFUbWVcAhDubM0tsvMjyuvE0jRq+THSCcvGLvwy+H U493JwlTB1gFoQTMKUf4Bg33qu+7eZ9DDu1kv7+75ywWG7owcXQzGQS79qCYWo5e venVfkiFQzJqw0v+Ipgdh7VIPX7ITspTj1dH+6e6mN6BeGcXYmN3B9M3IXKYjUTW URV/OjzYM0Y38FYjeZoRE9kYyxTCK4XWNiy4BzeA6HiBSy1iEo/RvaI+3gSsaNMh +6QhDNNkLMv92uxSleCBO20ur/FRKkZboDZsSHqHvXlKt+OPiRw3rAMLjM1+IcKY yUr0ojlIaADBalO5lPqgJbJUsXb3+nY4K7D6wiezMIxye69vSAN7LNEJeQZ9PjCs DtcfEdo2reZJWZj6DE6N =0+cf -----END PGP SIGNATURE----- --Sig_/0/QhloKmOsTJCYBxIpGG1vv--