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