[gentoo-dev] Re: systemd profiles

["Steven J. Long" <slong@rathaus.eclipse.co.uk>]

On Wed, Sep 03, 2014 at 03:27:15PM -0400, Rich Freeman wrote:
> On Wed, Sep 3, 2014 at 2:11 PM, William Hubbs <williamh@gentoo.org> 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 ;-)