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 0D1FA1387FD for ; Wed, 10 Sep 2014 03:00:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D7B43E09A5; Wed, 10 Sep 2014 03:00:06 +0000 (UTC) Received: from smtpout.karoo.kcom.com (smtpout.karoo.kcom.com [212.50.160.34]) by pigeon.gentoo.org (Postfix) with ESMTP id B3205E099E for ; Wed, 10 Sep 2014 03:00:05 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,495,1406588400"; d="scan'208";a="85770791" Received: from unknown (HELO rathaus.eclipse.co.uk) ([82.153.108.167]) by smtpout.karoo.kcom.com with ESMTP; 10 Sep 2014 04:00:05 +0100 Date: Wed, 10 Sep 2014 04:29:51 +0100 From: "Steven J. Long" To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: systemd profiles Message-ID: <20140910032950.GA5558@rathaus.eclipse.co.uk> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <5401080E.8090904@gentoo.org> <1863932.qRLQGIk0OP@andromeda> <20140830134126.2b1a6da7@pomiot.lan> <20140830145524.7446d838@shanghai.paradoxon.rec> <20140903181114.GA14334@linux1> 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-Disposition: inline In-Reply-To: X-Archives-Salt: 57bead24-e45d-4bfb-be02-6355aaa28e20 X-Archives-Hash: a154ba52dbcb879ad8929fb9dea2c7e3 On Wed, Sep 03, 2014 at 03:27:15PM -0400, Rich Freeman wrote: > On Wed, Sep 3, 2014 at 2:11 PM, William Hubbs wrote: > > > > I can deprecate it. To do so, I would need to have it print out a > > deprecation warning that would be wrong for Gentoo in the next release. > > > > That warning would have to tell users to source > > /lib*/rc/sh/functions.sh. > > I don't have a problem with openrc supplying an API. However, that > API should be limited to openrc-specific functions, and it really > shouldn't be used by anything else except for stuff like > starting/stopping services, determining the runlevel, or other > openrc-ish things. It shouldn't be used for utility functions. Well the reason the util API is provided by openrc is so that _programs_ running at init time can provide the output users love, as well as scripts. Yes they're trivial functionality and many a shell scripter has their own variant, but equally it makes sense to have one C wrapper, with a lib API, and not duplicate the code. Hence my strong disagreement with the removal of the API, which was reverted a few weeks after it was committed when it turned out to have a consumer after all. Obviously that fits your description of init-specific, and I don't have any issue at all with the shell lib being in one place either: it makes total sense, in the same way as having the lib API in openrc for init programs does. > It would probably make more sense to have a generic init-agnostic > Gentoo wrapper in /lib, and then have it call the appropriate > openrc/systemd/whatever functions based on how the system is > configured. Most usage is of really trivial stuff, so I don't think that should rely on any init-system at all: it's basic sh, minimal when done well. > If the decision is to stick that generic Gentoo script in /etc I don't > think it is the end of the world, Not at all: a sh file is simple text after all, unless ofc it's been complexified by someone who doesn't grok sh and obfuscated with insane bracing. The discussion was had a long time ago about the canonical location, which is separate from which package provides it: personally I'd do what vapier said and put it back in baselayout where it belongs. I don't care where it goes personally, so long as it's available at init and not in some nubEnterpriseFactory location, but I'd defer to vapier and UberLord if it were my call. I can see the reasoning that /etc provides for site-specific customisation, as well as config updates, in a location admins expect to customise, and indeed backup more strictly than some places. > but it probably shouldn't be provided by openrc. > In general we shouldn't have dependencies on an > init system unless the package is actually interacting with the init > system. Agreed. Regards, steveL -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)