| 1 |
On Wed, Sep 03, 2014 at 03:27:15PM -0400, Rich Freeman wrote: |
| 2 |
> On Wed, Sep 3, 2014 at 2:11 PM, William Hubbs <williamh@g.o> wrote: |
| 3 |
> > |
| 4 |
> > I can deprecate it. To do so, I would need to have it print out a |
| 5 |
> > deprecation warning that would be wrong for Gentoo in the next release. |
| 6 |
> > |
| 7 |
> > That warning would have to tell users to source |
| 8 |
> > /lib*/rc/sh/functions.sh. |
| 9 |
> |
| 10 |
> I don't have a problem with openrc supplying an API. However, that |
| 11 |
> API should be limited to openrc-specific functions, and it really |
| 12 |
> shouldn't be used by anything else except for stuff like |
| 13 |
> starting/stopping services, determining the runlevel, or other |
| 14 |
> openrc-ish things. It shouldn't be used for utility functions. |
| 15 |
|
| 16 |
Well the reason the util API is provided by openrc is so that _programs_ |
| 17 |
running at init time can provide the output users love, as well as scripts. |
| 18 |
Yes they're trivial functionality and many a shell scripter has their own |
| 19 |
variant, but equally it makes sense to have one C wrapper, with a lib |
| 20 |
API, and not duplicate the code. Hence my strong disagreement with the |
| 21 |
removal of the API, which was reverted a few weeks after it was committed |
| 22 |
when it turned out to have a consumer after all. |
| 23 |
|
| 24 |
Obviously that fits your description of init-specific, and I don't have |
| 25 |
any issue at all with the shell lib being in one place either: it makes |
| 26 |
total sense, in the same way as having the lib API in openrc for init |
| 27 |
programs does. |
| 28 |
|
| 29 |
> It would probably make more sense to have a generic init-agnostic |
| 30 |
> Gentoo wrapper in /lib, and then have it call the appropriate |
| 31 |
> openrc/systemd/whatever functions based on how the system is |
| 32 |
> configured. |
| 33 |
|
| 34 |
Most usage is of really trivial stuff, so I don't think that should |
| 35 |
rely on any init-system at all: it's basic sh, minimal when done well. |
| 36 |
|
| 37 |
> If the decision is to stick that generic Gentoo script in /etc I don't |
| 38 |
> think it is the end of the world, |
| 39 |
|
| 40 |
Not at all: a sh file is simple text after all, unless ofc it's been |
| 41 |
complexified by someone who doesn't grok sh and obfuscated with insane |
| 42 |
bracing. The discussion was had a long time ago about the canonical |
| 43 |
location, which is separate from which package provides it: personally |
| 44 |
I'd do what vapier said and put it back in baselayout where it belongs. |
| 45 |
|
| 46 |
I don't care where it goes personally, so long as it's available at init |
| 47 |
and not in some nubEnterpriseFactory location, but I'd defer to vapier |
| 48 |
and UberLord if it were my call. I can see the reasoning that /etc |
| 49 |
provides for site-specific customisation, as well as config updates, in |
| 50 |
a location admins expect to customise, and indeed backup more strictly |
| 51 |
than some places. |
| 52 |
|
| 53 |
> but it probably shouldn't be provided by openrc. |
| 54 |
|
| 55 |
> In general we shouldn't have dependencies on an |
| 56 |
> init system unless the package is actually interacting with the init |
| 57 |
> system. |
| 58 |
|
| 59 |
Agreed. |
| 60 |
|
| 61 |
Regards, |
| 62 |
steveL |
| 63 |
-- |
| 64 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |
Archives