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 B88A91381F3 for ; Sun, 26 May 2013 11:31:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E7971E0CBE; Sun, 26 May 2013 11:31:26 +0000 (UTC) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DC000E09F0 for ; Sun, 26 May 2013 11:31:25 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hn14so1504181wib.2 for ; Sun, 26 May 2013 04:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=DLPxYBtw3hkAmpX6/kQC+MMNVlMmE1KTLfkIHrDrzaw=; b=DgfsstI9NmQOV9pUySRRsC/8bMRz5Slwl34KNW+MEMaOLGQmQCJl9hGC8EMZUJuG70 7D4kb/ODQqrRlyMTqGwoo7IBMSKLiaXzq9iIHmv2npLRcIGGQcTiSttPr+3udox2u8jO IA6znqgjdiGBXMHilWfx8010z5KsBkKHimS7RCaKb3VLYBLKynKkqt4trjdCDgEwu0wq 6WFRCJynkOjPl1kB32srsvkrkfoK5CbEh+ZdguovLUB2PS0xse/FSGQ872TT8cI6bfGa uZf/6M2e9iZEJXn06D3K8/XXGxLXLZMzSzg6HtyJ0t++o6fulUOoLXtovZNPG9Ka0aMn H2aw== X-Received: by 10.194.216.39 with SMTP id on7mr5282108wjc.4.1369567884558; Sun, 26 May 2013 04:31:24 -0700 (PDT) Received: from localhost ([80.92.253.14]) by mx.google.com with ESMTPSA id cw8sm10324468wib.7.2013.05.26.04.31.23 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 26 May 2013 04:31:24 -0700 (PDT) Date: Sun, 26 May 2013 13:31:11 +0200 From: Robert David To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: gentoo-dev@lists.gentoo.org, 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: <20130526133111.5b8ae745@gmail.com> In-Reply-To: <20130526123125.2d0f7836@gentoo.org> References: <20130526093755.42b62259@gentoo.org> <20130526121249.49e00ce7@gmail.com> <20130526123125.2d0f7836@gentoo.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 59f54bc5-f7dd-4a82-8879-5f29d2d20cea X-Archives-Hash: f3b5d061f7735a14b6251edeb115d7d6 On Sun, 26 May 2013 12:31:25 +0200 Micha=C5=82 G=C3=B3rny wrote: > On Sun, 26 May 2013 12:12:49 +0200 > Robert David wrote: >=20 > > 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=C5=82 G=C3=B3rny wr= ote: > > > >> > > > >> 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. >=20 > This effectively duplicates data for no real benefit. >=20 > 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. >=20 > 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. >=20 > 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.