Bug 373219 – provide alternative for /etc/init.d/functions.sh so that openrc is not required

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Anthony Basile 2011-06-27 16:31:06 UTC]

Currently many packages such as gentoolkit, perl-cleaner, python-updater, etc, have scripts which source /etc/init.d/functions.sh.  But functions.sh is currently provided by openrc.  You should not have to emerge openrc just to provide functions.sh to these packages.

We should create  /usr/libexec/gentoo-functions.sh which would provide these functions to gentoolkit etc.  Also, /etc/init.d/functions.sh should be moved to /lib/rc and a deprecation warning added for those scripts which still source /etc/init.d/functions.sh.

Reproducible: Always

[Comment 1 SpanKY 2011-06-27 19:23:11 UTC]

ugh, no.  this file is needed before /usr is available, and we used to have it in /lib/, but that got messy.  we already went through the migration mess once with baselayout-1 to baselayout-2 and /etc/init.d/functions.sh was long ago decided to be the canonical name to avoid future issues.

[Comment 2 Anthony Basile 2011-06-27 19:32:54 UTC]

(In reply to comment #1)
> ugh, no.  this file is needed before /usr is available, and we used to have it
> in /lib/, but that got messy.  we already went through the migration mess once
> with baselayout-1 to baselayout-2 and /etc/init.d/functions.sh was long ago
> decided to be the canonical name to avoid future issues.

How do we avoid pulling in openrc just for functions.sh?  People who use systemd or who don't want an init system (chroots) need the later but not the former.

[Comment 3 SpanKY 2011-06-27 19:59:21 UTC]

you cant.  if you read functions.sh, you'll see that it isnt just a matter of exporting some shell functions.  many of the things you rely on (like `einfo`) are actually programs found via $PATH.

[Comment 4 William Hubbs 2011-06-27 20:11:38 UTC]

(In reply to comment #3)
> you cant.  if you read functions.sh, you'll see that it isnt just a matter of
> exporting some shell functions.  many of the things you rely on (like `einfo`)
> are actually programs found via $PATH.

That is not quite true;Actually, einfo, ewarn, etc are only found by $PATH when running under runscript. To see what I'm talking about, go to a root shell and try to use einfo directly. These are located in /lib/rc/{bin,sbin} which is not in the normal path.

It is fine for init scripts to use them, but I think that things like revdep-rebuild should not depend on openrc. If they want to use these functions they can, but it should not be a hard requirement for openrc to be there.

[Comment 5 SpanKY 2011-06-27 20:17:59 UTC]

the PATH aspect is irrelevant.  the point was that they're programs compiled and installed by openrc, and functions.sh simply provides access to those.

it is perfectly fine for Gentoo packages to use einfo/friends in their scripts.  it provides standardized output and has been the standard in Gentoo since the beginning.  banning Gentoo scripts from using these is not an acceptable solution.  i'm certainly not going for it with all the scripts i maintain.

[Comment 6 Christian Ruppert (idl0r) 2011-06-27 20:21:03 UTC]

Created attachment 278393 [details, diff]
Deprecte /etc/init.d/functions.sh

(In reply to comment #1)
> ugh, no.  this file is needed before /usr is available, and we used to have it
> in /lib/, but that got messy.  we already went through the migration mess once
> with baselayout-1 to baselayout-2 and /etc/init.d/functions.sh was long ago
> decided to be the canonical name to avoid future issues.

/etc/init.d/functions.sh already points to @LIBEXECDIR@/sh/functions.sh so it is available before /usr.

We wanted to deprecated the link in /etc/init.d/ so that gentoo uses a separate package which has a "copy" of functions.sh and openrc/other distros still use the one from @LIBEXECDIR@/sh/functions.sh.

[Comment 7 William Hubbs 2011-06-27 20:32:06 UTC]

(In reply to comment #5)
> it is perfectly fine for Gentoo packages to use einfo/friends in their scripts.
>  it provides standardized output and has been the standard in Gentoo since the
> beginning.  banning Gentoo scripts from using these is not an acceptable
> solution.  i'm certainly not going for it with all the scripts i maintain.

Please re-read my comment. I did not say anything about banning anything. I am just saying that someone should be able to do "emerge --unmerge openrc" and still have a system that works.

[Comment 8 SpanKY 2011-06-27 20:59:22 UTC]

(In reply to comment #6)
/etc/init.d/functions.sh must be available.  scripts do `. /etc/init.d/functions.sh` in order to bootstrap.

(In reply to comment #7)
that's fine, but i didnt say that openrc must provide these things.

all Gentoo systems must have:
 - /etc/init.d/functions.sh which can be sourced by shell code
 - that file must provide einfo/etc... funcs

any proposal which does not provide these is unacceptable.  further, maintaining two code bases is not acceptable.

[Comment 9 SpanKY 2011-06-27 21:01:03 UTC]

Comment on attachment 278393 [details, diff]
Deprecte /etc/init.d/functions.sh

no, we are not deprecating /etc/init.d/functions.sh

also, you should use -M when formatting patches to show file moves

[Comment 10 Christian Ruppert (idl0r) 2011-06-27 21:04:47 UTC]

(In reply to comment #8)
> (In reply to comment #6)
> /etc/init.d/functions.sh must be available.  scripts do `.
> /etc/init.d/functions.sh` in order to bootstrap.
> 
> (In reply to comment #7)
> that's fine, but i didnt say that openrc must provide these things.
> 
> all Gentoo systems must have:
>  - /etc/init.d/functions.sh which can be sourced by shell code
>  - that file must provide einfo/etc... funcs
> 
> any proposal which does not provide these is unacceptable.  further,
> maintaining two code bases is not acceptable.

Ok, another idea:
What if we add a minimal useflag to openrc which just builds and installs all
the einfo, ... binaries incl. functions.sh?

[Comment 11 SpanKY 2011-06-27 21:07:34 UTC]

an odd solution, but i'm not against it

[Comment 12 SpanKY 2011-06-27 21:08:05 UTC]

although, i have seen some people do USE=minimal in make.conf, and this would render their system unbootable ...

[Comment 13 Christian Ruppert (idl0r) 2011-06-27 21:35:14 UTC]

I would prefer a separate package and openrc depends on it.
The binaries/links could be still installed to either /lib/.. or even /bin.
So we don't have to maintain the code twice.

In gentoo we just skip those binaries/links in the openrc ebuild but install them through the new gentoo-functions (or however we'll call it) ebuild..
So other distros wouldn't need to install another packages just to get openrc running.

[Comment 14 William Hubbs 2011-06-27 21:48:06 UTC]

(In reply to comment #13)
> I would prefer a separate package and openrc depends on it.
> The binaries/links could be still installed to either /lib/.. or even /bin.
> So we don't have to maintain the code twice.

I don't really understand what you are suggesting here.

Are we wanting to force all gentoo users to have openrc installed to avoid maintaining a separate functions.sh file?

[Comment 15 SpanKY 2011-06-27 21:56:19 UTC]

i dont think we can split this stuff out of the openrc package itself as that'd break people trying to use it by hand (or make it a useless pita)

we could add an openrc-core ebuild that'd only build/install these core pieces.  and then alternative init peeps could install that instead of openrc.

[Comment 16 Christian Ruppert (idl0r) 2011-06-27 21:59:01 UTC]

(In reply to comment #15)
> i dont think we can split this stuff out of the openrc package itself as that'd
> break people trying to use it by hand (or make it a useless pita)
> 
> we could add an openrc-core ebuild that'd only build/install these core pieces.
>  and then alternative init peeps could install that instead of openrc.

Yeah, that's what I meant.

[Comment 17 William Hubbs 2011-06-27 22:13:34 UTC]

(In reply to comment #15)
> we could add an openrc-core ebuild that'd only build/install these core pieces.
>  and then alternative init peeps could install that instead of openrc.

Or, what about me figuring out a way in the openrc build system to build only the core components, then we could have that on by default, but have it controled by a use flag in the openrc ebuild.

[Comment 18 William Hubbs 2011-06-27 22:16:16 UTC]

(In reply to comment #17)
> (In reply to comment #15)
> > we could add an openrc-core ebuild that'd only build/install these core pieces.
> >  and then alternative init peeps could install that instead of openrc.
> 
> Or, what about me figuring out a way in the openrc build system to build only
> the core components, then we could have that on by default, but have it

Sorry, I meant off here.

I'm thinking of something like make MKCOREONLY=(yes/no) 

and it would be no by default.

[Comment 19 SpanKY 2011-06-27 22:20:58 UTC]

thanks, that should be the correct behavior ... default is build all and people have to explicitly request "core-only"

[Comment 20 William Hubbs 2011-06-28 19:21:34 UTC]

Created attachment 278537 [details]
0001-add-mkcoreonly-option.patch

All,

this adds a MKCOREONLY option to openrc's build system so it is possible
to remove the init script related portions. Please let me know what you
think.

[Comment 21 SpanKY 2011-06-29 03:41:55 UTC]

looks pretty straight forward, although i'm not sure about the MKPAM logic.  people have to manually do `make MKPAM=pam ...`, so if they're doing that with MKCOREONLY=yes, then sounds like a user error and not something we should be worrying about.

[Comment 22 William Hubbs 2011-06-29 16:34:41 UTC]

Created attachment 278625 [details]
0001-remove-the-link-at-SYSCONFDIR-init.d-functions.sh.patch


All,

here is a third proposal: If openrc adds this patch, which just drops
the symbolic link at /etc/init.d/functions.sh, baselayout, or some other
package, could provide an alternative /etc/init.d/functions.sh which can
be used by things other than init scripts. That way gentoo's core
functionality wouldn't be dependent on the init system.

If you like this patch I'll probably take it further and actually remove
the references to @libexecdir@/functions.sh from the man pages.

[Comment 23 William Hubbs 2011-06-29 17:30:00 UTC]

I have another idea in my head that I haven't written a patch for yet,
but it is a possibility.

Instead of a MKCOREONLY option, what about a MKINITSCRIPTS option which
would default to on, but if you add MKINITSCRIPTS=no to the
command line, we don't make the runlevels or init scripts? That might be
easier than trying to figure out what should be included in the
MKCOREONLY option.

I would control this with an init-scripts use flag and put a warning in
the ebuild if you turn this flag off.

[Comment 24 William Hubbs 2011-06-29 18:33:00 UTC]

Created attachment 278635 [details]
0001-make-building-init-scripts-optional.patch

All,

here is another possibility from the openrc side. the MKINIT option by
default will be on, but it can be turned off on the make command line.
If it is off, the init scripts and runlevels will not be installed. This
seems a bit more simple than trying to figure out what should be
included when using MKCOREONLY.

What do you think of this approach?

[Comment 25 SpanKY 2011-06-29 19:35:35 UTC]

Comment on attachment 278625 [details]
0001-remove-the-link-at-SYSCONFDIR-init.d-functions.sh.patch

we're not documenting /lib/sh/functions.sh as an acceptable entry point, nor are we doing to maintain two parallel code bases which do the exact same thing, nor are we going to have one package create a symlink that points to a file provided by some other package

[Comment 26 SpanKY 2011-06-29 19:38:13 UTC]

Comment on attachment 278635 [details]
0001-make-building-init-scripts-optional.patch

+ifneq (${MKINIT},no)
+	subdir += conf.d init.d local.d

the indentation/case on "subdir" seems wrong.  am i missing something ?

[Comment 27 William Hubbs 2011-06-29 20:08:13 UTC]

Created attachment 278645 [details]
0001-make-building-init-scripts-optional.patch

This patch fixes the indentation/case issue from the previous patch.

Any more thoughts about it?

William

[Comment 28 SpanKY 2011-06-29 23:40:08 UTC]

neither of these patches (mkcoreonly or mkinit) really satisfies the request at hand.  and USE flags controlling this sounds easy to bite people.

if we go the 2nd ebuild route (openrc-core), we could keep all the logic src_install as to what explicitly gets merged.

[Comment 29 William Hubbs 2011-06-30 02:39:26 UTC]

(In reply to comment #28)
> neither of these patches (mkcoreonly or mkinit) really satisfies the request at
> hand.  and USE flags controlling this sounds easy to bite people.

What do you mean neither of them really satisfies the request?

> if we go the 2nd ebuild route (openrc-core), we could keep all the logic
> src_install as to what explicitly gets merged.

Yes, but I think that will cause issues with dependencies.  Say that we have the ebuilds openrc-core and openrc for example. I think you will also need virtual/openrc which has || ( openrc openrc-core ) in its dependencies and openrc-core and openrc will have to block each other. The other possibility I can think of is for openrc to depend on openrc-core, but that isn't what we would want because  if you do that everyone is required to install both.

What am I missing?

[Comment 30 SpanKY 2011-06-30 03:45:41 UTC]

the request (from Anthony and the alternative-init-wankers) is basically that they dont want openrc.  it isnt a matter of not wanting the init.d scripts, or some random bins, or something else ... they dont want openrc at all.

the issue is that openrc provides /etc/init.d/functions.sh (and that relies on a few other pieces).  so any patch/ebuild we make has to provide just that.

the patches posted thus far dont go nearly far enough in getting us to the actual request posted.

when it comes to deps, the only thing pulling in openrc atm is baselayout.  openrc isnt part of system (some might consider this a bug).  but i dont envision packages right now depending on openrc themselves.  /etc/init.d/functions.sh is considered "part of the Gentoo base" and thus always available, which means baselayout itself (for now) would be updated with the ||() dep.  i dont think blockers between the two will be a problem.

[Comment 31 William Hubbs 2011-06-30 16:47:59 UTC]

(In reply to comment #30)
> the issue is that openrc provides /etc/init.d/functions.sh (and that relies on
> a few other pieces).  so any patch/ebuild we make has to provide just that.

I agree here. 

> the patches posted thus far dont go nearly far enough in getting us to the
> actual request posted.
> 
> when it comes to deps, the only thing pulling in openrc atm is baselayout. 
> openrc isnt part of system (some might consider this a bug).  but i dont
> envision packages right now depending on openrc themselves. 
> /etc/init.d/functions.sh is considered "part of the Gentoo base" and thus
> always available, which means baselayout itself (for now) would be updated with
> the ||() dep.  i dont think blockers between the two will be a problem.

I'm just about convinced that the second package approach is best. However, I like the name gentoo-base-functions better than openrc-core because that is what it is going to provide. In other words, I see it as a gentoo specific package now as opposed to an OpenRC feature.

I just briefly looked at /etc/init.d/functions.sh, and it did not appear to be a very complicated script. How difficult would it be to make
gentoo-base-functions include only a version of that script which would detect whether openrc is available and use it if it is or provide the functions itself if it is not? I see a couple of advantages to this. The first is that once it is stable it is stable; it would be a pretty low maintenance package. The second is that the dependency issue could be solved immediately by making
 gentoo-base-functions part of system.

I will grant you that there is a disadvantage to this which is the duplication of code/functionality between gentoo-base-functions and openrc. However I think it is worth that for the ease of maintenance of gentoo-base-functions once it is stabilized and for making gentoo-base-functions functional without OpenRC.

Using a stripped down openrc for gentoo-base-functions requires maintaining two blocking packages together.
Every time there is a new version of openrc released there will be a new version of gentoo-base-functions. Both of these packages will have to be version bumped, arch tested and stabilized together. I think that will cause more work for more people in the long term that is not really necessary.

What are your thoughts?

[Comment 32 William Hubbs 2011-06-30 18:17:36 UTC]

Here is more information about what I'm thinking about the script
/etc/init.d/functions.sh. OpenRC exports RC_LIBEXECDIR to scripts
running under runscript, so you could do the following at the top of the
script:

if [ -n "${RC_LIBEXECDIR} ]; then
 . "${RC_LIBEXECDIR}"/sh/functions.sh
else
	# do what you want here since OpenRC is not involved.
fi

[Comment 33 Anthony Basile 2011-06-30 18:33:33 UTC]

FWIW here's my feelings:

(In reply to comment #31)
> 
> I'm just about convinced that the second package approach is best. 

I am convinced it is the best approach, even though functions.sh is tiny.

> I will grant you that there is a disadvantage to this which is the duplication
> of code/functionality between gentoo-base-functions and openrc. However I think
> it is worth that for the ease of maintenance of gentoo-base-functions once it
> is stabilized and for making gentoo-base-functions functional without OpenRC.

I like the name gentoo-base-functions.

It does not have to be a duplication of code since openrc will depend on gentoo-base-functions and can source that.

> 
> Using a stripped down openrc for gentoo-base-functions requires maintaining two
> blocking packages together.

No see above point.

[Comment 34 William Hubbs 2011-06-30 21:25:26 UTC]

(In reply to comment #33)
> (In reply to comment #31)
> > 
> > I'm just about convinced that the second package approach is best. 
> 
> I am convinced it is the best approach, even though functions.sh is tiny.
> 
> > I will grant you that there is a disadvantage to this which is the duplication
> > of code/functionality between gentoo-base-functions and openrc. However I think
> > it is worth that for the ease of maintenance of gentoo-base-functions once it
> > is stabilized and for making gentoo-base-functions functional without OpenRC.
> 
> I like the name gentoo-base-functions.
> 
> It does not have to be a duplication of code since openrc will depend on
> gentoo-base-functions and can source that.

Look at comment #32. I am proposing that openrc relinquish all ownership of the the symbolic link at /etc/init.d/functions.sh, and this file should be created by gentoo-base-functions, which would be a separate package. The script in gentoo-base-functions would be able to detect whether openrc is available and it would use openrc if it is there but provide its own functions otherwise.

[Comment 35 William Hubbs 2011-06-30 22:01:53 UTC]

Actually my test works to see if /etc/init.d/functions.sh is being
sourced by something that was run under runscript, but not whether
openrc is actually _INSTALLED_. If gentoo wants to use OpenRC's versions
of the functions if openrc is installed as opposed to if the script
sourcing /etc/init.d/functions.sh is running under runscript or not, we
would need to agree on something to test to see if openrc is INSTALLED.

[Comment 36 Peter Volkov (RETIRED) 2011-07-01 12:08:58 UTC]

(In reply to comment #34)
> Look at comment #32. I am proposing that openrc relinquish all ownership of the
> the symbolic link at /etc/init.d/functions.sh, and this file should be created
> by gentoo-base-functions, which would be a separate package. The script in
> gentoo-base-functions would be able to detect whether openrc is available and
> it would use openrc if it is there but provide its own functions otherwise.

This way there will be two implementations for simple script. Why? It's much easier install symlink, script with gentoo-base-functions and disable their installation in openrc (with some Makefile option). It's really looks not nice to split functionality.

[Comment 37 William Hubbs 2011-07-01 13:28:35 UTC]

(In reply to comment #36)
> (In reply to comment #34)
> > The script in
> > gentoo-base-functions would be able to detect whether openrc is available and
> > it would use openrc if it is there but provide its own functions otherwise.
> 
> This way there will be two implementations for simple script. Why? It's much
> easier install symlink, script with gentoo-base-functions and disable their
> installation in openrc (with some Makefile option). It's really looks not nice
> to split functionality.

I agree that the symbolic link from /etc/init.d/functions.sh to /lib/rc/sh/functions.sh should not be installed by openrc.

On systems with OpenRc installed, init scripts will always use the functions OpenRC provides, so wouldn't we want gentoo-base-functions to use them as well?

[Comment 38 Peter Volkov (RETIRED) 2011-07-01 13:53:49 UTC]

Probably I was not clear. I mean both /etc/init.d/functions.sh and 
/lib/rc/sh/functions.sh be installed from gentoo-base-functions. Then the only customization required will be make openrc depend on it and not install both this files.

[Comment 39 William Hubbs 2011-07-01 15:05:06 UTC]

(In reply to comment #38)
> Probably I was not clear. I mean both /etc/init.d/functions.sh and 
> /lib/rc/sh/functions.sh be installed from gentoo-base-functions. Then the only
> customization required will be make openrc depend on it and not install both
> this files.

Everything under /lib/rc is owned by openrc, so gentoo-base-functions should not install anything there. Also, the /lib/rc/sh/functions.sh file is not independent; it requires the presence of openrc. Mostly it just adds /lib/rc/{bin,sbin) to your path. If you look in those two directories you will find that the files there are mostly symbolic links to /sbin/rc which is a multi call binary.

[Comment 40 William Hubbs 2011-07-03 23:28:26 UTC]

Created attachment 278999 [details]
functions.sh

All,

This is my idea for a possible /etc/init.d/functions.sh script which
would be installed by a package called gentoo-base-functions. If it is
sourced by an openrc init script, it will use openrc's versions of the
functions. Otherwise it provides its own functions.

I'm aware it is still rough and will not work as it stands,
but I want thoughts before I go further.

The remaining tasks I have for this will be to make sure it is in sync
with what openrc provides, remove bashisms so that it will run in a
posix environment, write a configuration file for it (which will be
called something like /etc/gentoo-base.conf), rework the code to read
it instead of /etc/conf.d/rc, and fix up the style.

So, I'm looking for comments. Would something like this work to make
sure people could have init systems other than OpenRC?

[Comment 41 SpanKY 2011-07-05 01:23:58 UTC]

there's quite a bit of logic here, and exports quite a lot more than should be.  seems like you just took the current baselayout-1 functions.sh and put a wrapper around it ?

if you're going to make it install alongside of openrc instead of replacing it, then it doesnt make much sense to create yet another package.  we'd simply add it back to baselayout.

[Comment 42 William Hubbs 2011-07-05 02:32:47 UTC]

Before we add it anywhere, I want to see what we can get rid of in that
file.

Yes a lot of it came from baselayout-1, but I'm working on it here more
as I write this. I added yesno() from openrc to it because I find that
function to be very useful. Also, I am working on making it more posix
and getting rid of bashisms. You said you think there is more in there
than there should be, what do you suggest removing?

Yes, we could put functions.sh back in baselayout. The reason I
suggested a separate gentoo-base-functions package is because there is
precedent in other distros for having a package that is common
functions/utilities for the distribution,  e.g. debianutils, and I
thought it would be a good idea to follow that lead.

What do you think?

[Comment 43 SpanKY 2011-07-05 05:20:09 UTC]

pretty much every env var in there doesnt belong, nor does it need to source any other file

i dont think functions.sh falls into the general utils category.  it belongs more in the baselayout category as part of the filesystem.

[Comment 44 SpanKY 2011-08-21 16:10:47 UTC]

*** Bug 379595 has been marked as a duplicate of this bug. ***

[Comment 45 5FBCDB43 2011-12-11 12:14:25 UTC]

I have a question. Does scripts using functions.sh are also using programs provided by OpenRC?
If they not we could make the /etc/init.d/functions.sh symlink managed by eselect and openrc would have the script for its programs like it does now, and systemd (and others) would have a script that does the same for them that comes with the init system ebuild. Things like `rc-status --runlevel` are certainly not compatible with init systems not having runlevels, like systemd for example.

[Comment 46 Canek Peláez Valdés 2012-02-23 19:47:47 UTC]

Hi; simple Gentoo user here. I have "succeeded" in making my systems work without OpenRC... or at least they boot and everything I normally do I'm still able to do it (as far as I have tested).

I created a (very experimental, IMHO) overlay and set of instructions to do the same, you can look at them at:

http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/index.html

I don't know what the correct solution for the /etc/init.d/functions.sh file is, but I think the dependency on OpenRC should be explicitly stated in the ebuilds of packages that source this file, so at least people (like me) who try to remove OpenRC from their systems know about it.

And, I know it's not the proper solution, but at least with gcc-config I was able to keep functionality (again, as far as I have tested) by creating a dummy functions.sh file that basically replace ewarn, eerror, and friends with wrappers around printf. Since most packages that source functions.sh only use those (I think), maybe the logging functions could be separated from OpenRC and made available as a separate package.

The description of OpenRC is "OpenRC manages the services, startup and shutdown of a host"; I don't think none of that has to do with pretty log functions, so a separate package (which will also avoid code duplication) sounds like a reasonable answer.

[Comment 47 Canek Peláez Valdés 2012-02-29 22:03:58 UTC]

Created attachment 303775 [details]
einfo and related functions alternative implementation

I have implemented a (as far as I have tested) pixpel perfect implementation of the einfo and related functions from /etc/init.d/functions.sh. In my systems, the only scripts that source /etc/init.d/functions.sh are (according to a quick grep on /bin, /sbin, /usr/bin and /usr/sbin):

/sbin/fix_libtool_files.sh:      sys-devel/gcc
/usr/bin/binutils-config:        sys-devel/binutils-config
/usr/bin/gcc-config:             sys-devel/gcc-config
/usr/bin/java-1.5-fixer:         dev-java/java-config-wrapper
/usr/bin/java-check-environment: dev-java/java-config-wrapper
/usr/bin/revdep-rebuild:         app-portage/gentoolkit
/usr/sbin/locale-gen:            sys-libs/glibc
/usr/sbin/perl-cleaner:          app-admin/perl-cleaner
/usr/sbin/python-updater:        app-admin/python-updater

In

https://github.com/canek-pelaez/gentoo-systemd-only

you can find alternative ebuilds for all of these packages. This new ebuilds depend on a new package sys-libs/elog-functions that simply installs the file I'm attaching. The scripts are the same, but they source the attached script instead of /etc/init.d/functions.sh

I don't provide alternative versions for sys-devel/gcc and sys-libs/glibc: I'm not confident enough to provide alternative versions of such complicated ebuilds. However, I manually edited fix_libtool_files.sh and locale-gen, and they seem to be working as usual.

If my implementation of the einfo and related functions is incomplete or does something wrong, I'm willing to keep fixing it, but I think that if I can implement a workable implementation in 150 lines of Bash in a couple of days, there is no reason for all the packages mentioned above to depend on sys-apps/openrc for such a simple functionality. Even more if said functionality has really nothing to do with the primary purpose of OpenRC.

If some dev is willing to get this little script I'm attaching into the portage tree, we can try to talk to the maintainers of the above packages so they can source it instead of /etc/init.d/functions.sh. Since my little script can be installed alongside OpenRC, we can even do it without bothering OpenRC's maintainers nor devs.

This would allow us to address the problem William mentioned in comment #7: a user 'should be able to do "emerge --unmerge openrc" and still have a system that works.'

[Comment 48 Oleh 2012-09-15 14:09:02 UTC]

In some cases, like building stages, gcc-config built before openrc (openrc is not even building into stage1, for example). When gcc built, gcc-config runs and, obviously it cannot find functions.sh.

>>> Regenerating /etc/ld.so.cache...
/usr/bin/gcc-config: line 19: /etc/init.d/functions.sh: No such file or directory
gcc-config: Could not source /etc/init.d/functions.sh!

Why not to move the script into baselayout, for example?

[Comment 49 Daniel Robbins 2012-09-15 19:35:29 UTC]

I would suggest the approach outlined here: http://jira.funtoo.org/browse/FL-101

Basically, if /etc/init.d/functions.sh does not exist, substitute dummy functions in their place. This eliminates the dependency on OpenRC since things can still work without it, like during stage builds, etc.

[Comment 50 Canek Peláez Valdés 2012-09-15 19:59:35 UTC]

(In reply to comment #49)
> I would suggest the approach outlined here:
> http://jira.funtoo.org/browse/FL-101
> 
> Basically, if /etc/init.d/functions.sh does not exist, substitute dummy
> functions in their place. This eliminates the dependency on OpenRC since
> things can still work without it, like during stage builds, etc.

I very much like this approach. We cold do something like:

if [ -e /etc/init.d/functions.sh ]; then
    . /etc/init.d/functions.sh || die "Could not source /etc/init.d/functions.sh!"
else
    . ${DUMMY_IMPLEMENTATION} || die "Could not source ${DUMMY_IMPLEMENTATION}!"
fi

I believe William has a functional shell implementation of the functions provided by /etc/init.d/functions.sh; or, if the devs want to, I've been using this implementation:

https://github.com/canek-pelaez/gentoo-systemd-only/blob/master/sys-libs/elog-functions/files/elog-functions.sh

in my systemd-only overlay (it requires ncurses).

Whatever the choice, ${DUMMY_IMPLEMENTATION} could live either in baselayout, or in a package in @system.

[Comment 51 Francisco J. Vazquez 2013-04-19 08:38:33 UTC]

So, after almost two years, is this still going to happen or has been abandoned? Systemd seems to be well supported by gentoo as an alternative init and everything is working great here (including replacing sysvinit with systemd-sysv-utils).

[Comment 52 Pavel Volkov 2013-04-19 15:03:40 UTC]

systemd-sysv-utils is masked:

/usr/portage/profiles/package.mask:
# Michał Górny <[e-mail]> (21 Jan 2012)
# Blocks sysvinit yet doesn't provide all tools provided by it.
# Masking until we get the necessary tools out of sysvinit.
sys-apps/systemd-sysv-utils

Is this reasoning still true?

[Comment 53 Markus Rathgeb 2013-04-20 09:28:06 UTC]

My last call to gcc-config complains about missing /etc/init.d/functions.sh.
I created a symlink so /etc/init.d/functions.sh points to the elog-functions.sh from Canek Peláez Valdés gentoo-systemd-only overlay.
gcc-config is working fine with it, but IMHO we need to fix it.

https://github.com/canek-pelaez/gentoo-systemd-only/blob/master/sys-libs/elog-functions/files/elog-functions.sh

[Comment 54 Timothy Jones 2013-04-23 01:50:29 UTC]

Here is openrc ebuild, which provides yet another implementation of functions.sh

https://github.com/holliday/holliday/tree/master/sys-apps/openrc

Actually, that's all it does -- just provides funstions.sh. :)

[Comment 55 Boney McCracker 2013-04-26 01:52:07 UTC]

An opinion:

Architecturally, it seems obvious that the functions be extracted from OpenRC and delivered separately (say, "sys-apps/gentoo-functions", depended upon by baselayout).

There seems to be growing consensus that alternatives to OpenRC should be possible.  If so, it should not be necessary to have OpenRC installed just to provide a two-page script.  While it might appeal to those who wish to minimize change, it would also be confusing and illogical to keep it within OpenRC and toggle away the rest of OpenRC with USE flags.

The functions should be moved to a separate ebuild depended upon by baselayout.  They should be installed in /lib and sourced directly from that location.  The  symlink "/etc/init.d/functions.sh" can be maintained for some time to avoid causing mayhem (owned by the new parent package of the target, "sys-apps/gentoo-functions"), and the symlink should indeed be deprecated and eventually done away with.

I realize this seems like chaos, thrashing, and unwelcome change to SpanKY and probably others, but if we're going to support systemd as an alternative, I think it's the architecturally correct way to go about it.

It's one file.  One package.  This is not armageddon, and we've probably had ample time to mull it over by now.

[Comment 56 Francisco J. Vazquez 2013-04-26 15:23:00 UTC]

(In reply to comment #55)
> It's one file.  One package.  This is not armageddon, and we've probably had
> ample time to mull it over by now.

Well, not counting Daniel Robbins the last dev commented almost 2 years ago, so they don't seem to give a flying fuck about this bug anymore.

[Comment 57 Timothy Jones 2013-04-26 15:36:52 UTC]

Another thing of note (or maybe not), is that the only things using functions.sh on my system are gcc-config, python-updater, perl-cleaner and none of them have a dependency on openrc. Shouldn't they?

It seems the case for gentoo-functions ebuild is growing.

Could one of the devs please comment on it?

[Comment 58 Boney McCracker 2013-04-26 19:18:55 UTC]

(In reply to comment #56)
> (In reply to comment #55)
> > It's one file.  One package.  This is not armageddon, and we've probably had
> > ample time to mull it over by now.
> 
> Well, not counting Daniel Robbins the last dev commented almost 2 years ago,
> so they don't seem to give a flying fuck about this bug anymore.
This is not the place for ranting, particularly with language like that.

[Comment 59 Boney McCracker 2013-04-26 19:34:09 UTC]

The other architecturally clean possibility is to leave these functions where they are and simply modify the handful of ebuilds that call them to be independent of them.  If the OpenRC developers are unwilling to split off the functions, then that is course of action which must be pursued.

[Comment 60 William Hubbs 2013-04-26 19:35:40 UTC]

I will come back to this shortly and generate an ebuild/package to
handle this issue.

[Comment 61 William Hubbs 2013-04-26 21:41:51 UTC]

Here are my current thoughts on this issue, please comment.

- OpenRC should drop the creation of the /etc/init.d/functions.sh symlink.

- I still think we should create a package, gentoo-base-functions, which would include a functions.sh file, then we could add this to @system. This file could be put in baselayout, but that ties it to the baselayout release cycle, which I'm not sure I want to do.

- I am considering installing this file in /lib/gentoo/functions.sh and having /etc/init.d/functions.sh as a symlink to it for a while for backward compatibility.

- This file doesn't really have to worry about whether or not it is running under OpenRC, because everything that runs under OpenRC has a runscript shebang line so it will get OpenRC's functions.sh automatically via /lib/rc/runscript.sh.

[Comment 62 Boney McCracker 2013-04-27 00:09:20 UTC]

What about the rest of it (the pertinent symlinks currently in /lib/rc/bin and the relevant portions of the binary /sbin/rc)?

[Comment 63 Nikoli 2013-07-04 15:41:31 UTC]

Comment 61 sounds like a good plan, when do you plan to commit gentoo-base-functions package?

[Comment 64 William Hubbs 2013-07-05 04:52:50 UTC]

I have been swamped, so I'll do this as soon as I can.
Thanks for your patience,

William

[Comment 65 Fpemud 2013-07-16 10:22:29 UTC]

Glad to see this bug, thanks for the effort.
For one thing, I'm trying systemd and perhaps will switch to systemd later; for the second, I think a loosely coupled package structure is good in nature.
I'm no expert but I also have the feeling that functions.sh in /etc/init.d is not a good design.

[Comment 66 Ray Griffin (rorgoroth) 2013-08-03 08:13:01 UTC]

(In reply to William Hubbs from comment #64)
I just read your openrc 'announcement' on the dev ML, is it still going to be containing the functions.sh leaving us non-openrc-ers to source our own?

There seems to be a slight boom in wanting to get rid of openrc since the gnome depends on systemd becoming a thing and people can (from what I can tell) now depclean away openrc, sysvinit, etc. 

+ Another thanks for stepping up to finally get this done.

[Comment 67 Ryan Reich 2013-08-03 13:55:51 UTC]

I have been following this thread as well, because I was just bitten by the missing-openrc issue after upgrading to gnome-3.8 and being forced to switch to systemd.  The visible cause of the problem, now, is that (as Ray Griffin says) openrc can and will be removed by emerge --depclean even though some packages (in my case, gentoolkit, in particular revdep-rebuild) have a runtime dependency on it.  This is a clear failure of the build system that probably happens frequently (if silently) now that systemd is being pushed by one of the major DEs.

My thought is that functions.sh should not be used by any package outside the openrc scripts.  Tools like revdep-rebuild can get their message functions from portage since they are basically a part of it, and others should be freed from the assumption that a particular system setup exists, unless of course their maintainers want to add openrc as a dependency.  Which is a logical error, now that systemd is semi-required.

[Comment 68 Boney McCracker 2013-08-03 14:50:51 UTC]

"Resistance is futile."

[Comment 69 Ian Stakenvicius (RETIRED) 2013-08-08 18:45:44 UTC]

So it's really late in the game to bring this up, but grobian made a minimalist fork of openrc called 'einfo' which provides precisely what is necessary here; it's used in the baselayout-prefix package right now.

Why don't we just shove this into its own package in the tree?  This could've been done long ago; all the work's already done for us.

---

On a related note, whatever solution gets used here is going to require careful collision avoidance with baselayout-prefix.

[Comment 70 Lee Trager 2013-08-14 08:32:09 UTC]

At the very least shouldn't gcc-config depend on OpenRC? I removed OpenRC from my system when I migrated to systemd since I no longer had any dependencies on it. I updated binutils the other day which is forcing me to emerge OpenRC just to fix the broken binutils symlinks!

[Comment 71 Pavel Volkov 2013-08-14 08:49:40 UTC]

(In reply to Lee Trager from comment #70)
> At the very least shouldn't gcc-config depend on OpenRC? I removed OpenRC
> from my system when I migrated to systemd since I no longer had any
> dependencies on it. I updated binutils the other day which is forcing me to
> emerge OpenRC just to fix the broken binutils symlinks!

Can you please elaborate which symlinks were broken?
I unmerged openrc and sysvinit, too, and haven't noticed anything going wrong.

[Comment 72 Peter Sääf 2013-08-14 17:31:49 UTC]

It is the ones in /usr/bin that points to /usr/x86_64-pc-linux-gnu/binutils-bin/x.xx.x that breaks. I have had to fix them manually several times.

[Comment 73 Carter Young 2013-08-14 21:38:33 UTC]

I'm glad I read this... I've been trying to migrate from GNOME 3.6 to GNOME 3.8 to Unity for the past 4 days now... I think in light of this and other fascinating reads, I think I'll go back to KDE...

[Comment 74 William Hubbs 2013-08-15 19:19:28 UTC]

All,

here is the plan for this; I had to get OpenRC-0.12 into the tree first
due to some other packages that need it.

I am working on cleaning up the bashisms in the script I am going to
submit to the tree as gentoo-base-functions.

@vapier:
I want your comments on this part.

I would like to install it as /lib/gentoo/functions.sh; let me explain
why.

If we fix the packages in the tree so they source the correct path
(/lib/gentoo/functions.sh is what I'm thinking), then have OpenRC drop
the symlink and have gentoo-base-functions take it over. This would mean
if users aren't using the /etc/init.d/functions.sh symlink in their
custom scripts, non-OpenRC users could add /etc/init.d to
INSTALL_MASK and not have that directory
on their systems at all.

Thoughts?

William

[Comment 75 Lee Trager 2013-08-16 07:00:53 UTC]

(In reply to William Hubbs from comment #74)
> All,
> 
> here is the plan for this; I had to get OpenRC-0.12 into the tree first
> due to some other packages that need it.
> 
> I am working on cleaning up the bashisms in the script I am going to
> submit to the tree as gentoo-base-functions.
> 
> @vapier:
> I want your comments on this part.
> 
> I would like to install it as /lib/gentoo/functions.sh; let me explain
> why.
> 
> If we fix the packages in the tree so they source the correct path
> (/lib/gentoo/functions.sh is what I'm thinking), then have OpenRC drop
> the symlink and have gentoo-base-functions take it over. This would mean
> if users aren't using the /etc/init.d/functions.sh symlink in their
> custom scripts, non-OpenRC users could add /etc/init.d to
> INSTALL_MASK and not have that directory
> on their systems at all.
> 
> Thoughts?
> 
> William

+1

[Comment 76 Ulrich Müller 2013-08-27 07:13:09 UTC]

I've temporarily added openrc to the system set until this will be resolved, see bug 478764 comment #9.

[Comment 77 Pacho Ramos 2013-08-27 07:42:41 UTC]

Thanks Ulm

[Comment 78 Alex Xu (Hello71) 2013-08-27 13:11:57 UTC]

For those who have already installed functions.sh manually, you can disable the installation by removing openrc from the system set with:

    echo "-*sys-apps/openrc" >> /etc/portage/profile/packages

Do *not* use package.provided for this purpose.

[Comment 79 Boney McCracker 2013-08-27 15:19:16 UTC]

Will somebody be creating the official Gentoo documentation on how to implement systemd, updated with this latest information?

Is there going to be a branch section within the handbook for new installs?

[Comment 80 Alex Xu (Hello71) 2013-08-27 15:28:57 UTC]

(In reply to John Brendler from comment #79)
> Will somebody be creating the official Gentoo documentation on how to
> implement systemd, updated with this latest information?
> 
> Is there going to be a branch section within the handbook for new installs?

Official documentation: https://wiki.gentoo.org/wiki/Systemd

Gentoo is full of choices. It is not possible to have every possible choice inside the handbook.

[Comment 81 Boney McCracker 2013-08-27 15:41:02 UTC]

(In reply to Alex Xu from comment #80)
> (In reply to John Brendler from comment #79)
> > Will somebody be creating the official Gentoo documentation on how to
> > implement systemd, updated with this latest information?
> > 
> > Is there going to be a branch section within the handbook for new installs?
> 
> Official documentation: https://wiki.gentoo.org/wiki/Systemd
> 
> Gentoo is full of choices. It is not possible to have every possible choice
> inside the handbook.
Well, I don't personally care, but it seems to me that if most users are going to install a freedesktop.org environment depending on systemd, it's a bit cruel to walk them through the process of setting up openrc just right, only for them to have to turn around and trash it all in the next step.

[Comment 82 Pacho Ramos 2013-08-27 17:03:05 UTC]

Will use bug 482694 for that as it's unrelated with this bug report (and patches against the guidexml code will be highly welcome as I hate write doc using that :P)

[Comment 83 yegle 2013-08-28 23:48:30 UTC]

(In reply to Ulrich Müller from comment #76)
> I've temporarily added openrc to the system set until this will be resolved,
> see bug 478764 comment #9.

This is no good for gentoo-prefix users. sys-apps/openrc is not available at least to gentoo-prefix users on OSX.

[Comment 84 Jonathan Callen (RETIRED) 2013-09-02 00:18:35 UTC]

(In reply to yegle from comment #83)
> (In reply to Ulrich Müller from comment #76)
> > I've temporarily added openrc to the system set until this will be resolved,
> > see bug 478764 comment #9.
> 
> This is no good for gentoo-prefix users. sys-apps/openrc is not available at
> least to gentoo-prefix users on OSX.

sys-apps/openrc has been removed from @system on prefix.  $EPREFIX/etc/init.d/functions.sh is provided by sys-apps/baselayout-prefix on prefix systems.

[Comment 85 Alex Xu (Hello71) 2013-09-18 11:21:42 UTC]

Progress?

[Comment 86 Markos Chandras (RETIRED) 2013-10-16 07:46:49 UTC]

*** Bug 488170 has been marked as a duplicate of this bug. ***

[Comment 87 Alex Xu (Hello71) 2013-10-20 17:50:55 UTC]

Poke.

[Comment 88 Fpemud 2013-10-28 15:34:48 UTC]

Poke too

[Comment 89 William Hubbs 2013-10-29 19:40:27 UTC]

Just a quick update.
Once OpenRC-0.12.x hits stable, I will come back to this.

[Comment 90 SpanKY 2013-11-07 20:28:39 UTC]

*** Bug 490467 has been marked as a duplicate of this bug. ***

[Comment 91 SpanKY 2013-11-30 20:56:15 UTC]

*** Bug 478472 has been marked as a duplicate of this bug. ***

[Comment 92 Pavel Volkov 2013-11-30 21:02:44 UTC]

Excuse me, I'll bump this.
0.12 is stable.

[Comment 93 SpanKY 2013-11-30 21:35:23 UTC]

Comment on attachment 303775 [details]
einfo and related functions alternative implementation

this is not portable.  "function" keywords won't fly, neither will `echo -ne`.  didn't really look beyond those two obvious errors.

[Comment 94 poncho 2013-11-30 23:40:27 UTC]

I use https://github.com/marcusatbang/efunctions with the ebuild from https://github.com/coreos/coreos-overlay/tree/master/sys-apps/efunctions

[Comment 95 SpanKY 2013-12-01 07:47:15 UTC]

i've been pondering this of late.  seems like we could add a reduced copy back to baselayout and only install when it is built with USE=-openrc.  that way the system would not get into an inconsistent state.

baselayout would do:
 PDEPEND="openrc? ( sys-apps/openrc )
   !openrc? ( !sys-apps/openrc )"

openrc itself would DEPEND on sys-apps/baselayout[openrc(+)]

on the topic of relocating the file, that's orthogonal and shouldn't block this issue.

[Comment 96 William Hubbs 2013-12-02 07:33:36 UTC]

@vapier:
Can we chat about this on IRC at some point? I would like to have a
better understanding of why you want to put this in baselayout vs a
separate package such as gentoo-base-functions?

My thought is to put it in /lib/gentoo/gentoo-base-functions.sh, then
fix the packages other than OpenRC to source that file directly instead
of /etc/init.d/functions.sh. We could create that symbolic link in
/etc/init.d/functions.sh if we want after we remove it from OpenRC for
compatibility for a while then we could remove it.

[Comment 97 SpanKY 2013-12-07 09:06:48 UTC]

Created attachment 364774 [details]
trimmed functions.sh

i took the last functions.sh william e-mailed me and cleaned it up a bit more

[Comment 98 Manuel Nickschas 2013-12-25 18:19:37 UTC]

When using this script instead of OpenRC, running python-updater or perl-cleaner gives me tons of these:

/etc/init.d/functions.sh: line 25: [: -gt: unary operator expected
/etc/init.d/functions.sh: line 35: [: -gt: unary operator expected

[Comment 99 Ulf Dambacher 2014-01-09 13:09:37 UTC]

Can we please have virtual/efunctions that all packages which use /etc/init.d/functions.sh can depend on and then remove the hardcoded sys-apps/openrc from portage/profiles/base/packages ?

This virtual then can either pull sys-apps/openrc or any new ebuild which provides /etc/init.d/functions.sh.

I will add the relevant ebuilds as attachmend now:
virtual/efunctions-0 for upstream
sys-apps/efunctions for testing an alternative
virtual/efunctions-1  installing with alternative

you can find a copy at https://github.com/ulda/gentoo-ulda

[Comment 100 Ulf Dambacher 2014-01-09 13:10:38 UTC]

Created attachment 367476 [details]
virtual/efunctions-0.ebuild

virtual to get functions.sh dependencies tagged

[Comment 101 Ulf Dambacher 2014-01-09 13:11:46 UTC]

Created attachment 367478 [details]
sys-apps/efunctions.ebuild

alternative of functions.sh and other efunctions if you don't want sys-apps/openrc around

[Comment 102 Ulf Dambacher 2014-01-09 13:12:32 UTC]

Created attachment 367480 [details]
virtual/efunctions-1.ebuild

updated virtual/efunctions to add sys-apps/efunctions.ebuild

[Comment 103 Ulf Dambacher 2014-01-09 13:20:24 UTC]

Created attachment 367482 [details, diff]
patch for packages/base to use virtual/efunctions

[Comment 104 Tom Wijsman (TomWij) (RETIRED) 2014-01-27 22:14:26 UTC]

Ping, we're a month further; are currently down to ~30 votes and ~100 comments.

Can we look into comment #98 and/or from comment #99 to comment #103?

What's there left to do here? Are there still problems? Do we need more testing?

Thank you very much in advance. Have CC-ed QA to follow up and/or support this.

[Comment 105 Manuel Nickschas 2014-01-27 22:32:20 UTC]

Regarding #98, I've figured out that it's caused by tools calling eindent and eoutdent without parameter.

In my local version of the script, I've simply replaced the two

[ ${i} -gt 0 ]

in lines 25 and 35 by

[[ "${i}" -gt 0 ]]

and I am now using this instead of OpenRC (which I fully unmerged on my systemd-based boxen) without noticing any regressions in daily use (however, I didn't do real testing besides running things like python-updater and some other tools).

[[ ]] is a bashism, as far as I know, and thus may not be acceptable in the official script, but works for me.

Disclaimer: I can use Google much better than writing bash or shell script.

[Comment 106 William Hubbs 2014-01-27 23:07:09 UTC]

I sent vapier an email sometime back with my take on what the official
script might look like, but he never responded.

I'll look and see if I can find it to attach.

@vapier:
Do you have the email I sent you sometime back wrt this issue?

[Comment 107 William Hubbs 2014-01-28 00:15:30 UTC]

Created attachment 368936 [details]
functions.sh

All,

this is the functions.sh replacement I have been working on.

It is still rough, but I was waiting for vapier to take a look at it
before I posted it.

Anyone who wants to take a look at it and give me comments is welcome.

My goal is to put this in a package, gentoo-base-functions.sh, which
will actually install the file in /lib/gentoo/functions.sh, then we will
need to figure out what to do with the /etc/init.d/functions.sh symlink
in OpenRC since OpenRC scripts do not need it.

[Comment 108 Ulrich Müller 2014-01-28 00:18:23 UTC]

(In reply to William Hubbs from comment #107)
> Created attachment 368936 [details]
> functions.sh

This is incomplete. For example, it misses rc_runlevel() which is used by eselect.

[Comment 109 William Hubbs 2014-01-28 04:28:44 UTC]

(In reply to Ulrich Müller from comment #108)
> This is incomplete. For example, it misses rc_runlevel() which is used by
> eselect.

It looks like the rc.eselect module is for OpenRC based systems only, so the correct fix for this issue is going to be to fix source_rc_functions() to source the correct functions.sh.

What else is missing?

Thanks,

William

[Comment 110 David Heidelberg (okias) 2014-02-06 20:16:27 UTC]

reminder, solving this really should help us, can you comment it Ulrich?

[Comment 111 Ulrich Müller 2014-02-07 00:43:51 UTC]

(In reply to David Heidelberger (okias) from comment #110)
> reminder, solving this really should help us, can you comment it Ulrich?

As I said in comment 108, the proposed change will break eselect's rc module.
We agreed on the interface long time ago (around 2009, I can find uberlord's message if you want), and that the canonical location of the file should be in /etc/init.d/functions.sh.

[Comment 112 Boney McCracker 2014-02-07 01:04:17 UTC]

Things have changed since 2009, and that decision no longer makes sense.

[Comment 113 Ulrich Müller 2014-02-07 02:21:19 UTC]

(In reply to BoneKracker from comment #112)
> Things have changed since 2009, and that decision no longer makes sense.

It makes a lot of sense _not_ to change a "canonical location" all the time.

[Comment 114 Boney McCracker 2014-02-07 03:42:20 UTC]

I understand and agree.  However, there is also the question of good practice: where should shared components of the Gentoo base architecture reside (both in terms of filesystem hierarchy and package ownership).

Are there other such shared elements of Gentoo packages?  Will there be in the future?  Is it worth setting a useful precedent that prescribes a logical method of handling them?

I can't answer those questions, but I suppose now is the time to ask.

[Comment 115 Ulf Dambacher 2014-02-07 08:08:16 UTC]

Can you please set aside the argument about how featurerd functions.sh should be and create a solution?

I proposed one in comment 99!

Pros:
* For users of openrc nothing changes
* users of other init systems (including systemd) get a viable solution if they install am alternative package for functions.sh like proposed here
* ebuilds depending on /etc/init.d/functions.sh get flaged without breaking and can be dealed with later.
* multiple alternative versions of functions.sh can coexist, the user can select one by emerging and setting the link (eselect could help here, too)

Cons:
* someone has to maintain alternative functions.sh ebuilds
* functions.sh implementation other than the openrc one may be incomplete

This bug is now 3 years old!
What are you waiting for? 
In your favour I presume this is not a masked anti-systemd behaviour!

[Comment 116 Tom Wijsman (TomWij) (RETIRED) 2014-02-07 14:34:06 UTC]

(In reply to Ulrich Müller from comment #111)
> We agreed on the interface long time ago (around 2009, I can find uberlord's
> message if you want), and that the canonical location of the file should be
> in /etc/init.d/functions.sh.

Why would such file be in a directory that is supposed to contain start / stop scripts? Especially when it is consumed by other files that are not start / stop scripts? This bug attempts to provide an alternative; in this respect, WilliamH (and others) are suggesting replacements. The original interface is past its life time; it might have made sense back then, but I wonder whether it still does now.

[Comment 117 William Hubbs 2014-02-07 18:08:51 UTC]

(In reply to Ulrich Müller from comment #111)
> (In reply to David Heidelberger (okias) from comment #110)
> > reminder, solving this really should help us, can you comment it Ulrich?
> 
> As I said in comment 108, the proposed change will break eselect's rc module.
> We agreed on the interface long time ago (around 2009, I can find uberlord's
> message if you want), and that the canonical location of the file should be
> in /etc/init.d/functions.sh.

As I said above, we put this new file in /lib/Gentoo/functions.sh, then we transition the things that are sourcing /etc/init.d/functions.sh away from using that link.

eselect rc will be broken by default if OpenRc is removed, because it is an OpenRc specific module.

Another good reason for changing this canonical location is to allow non-OpenRc users to add /etc/init.d to INSTALL_MASK to block the installation of OpenRc scripts.

[Comment 118 Anthony Basile 2014-02-08 15:57:27 UTC]

(In reply to William Hubbs from comment #117)
> (In reply to Ulrich Müller from comment #111)
> > (In reply to David Heidelberger (okias) from comment #110)
> > > reminder, solving this really should help us, can you comment it Ulrich?
> > 
> > As I said in comment 108, the proposed change will break eselect's rc module.
> > We agreed on the interface long time ago (around 2009, I can find uberlord's
> > message if you want), and that the canonical location of the file should be
> > in /etc/init.d/functions.sh.
> 
> As I said above, we put this new file in /lib/Gentoo/functions.sh, then we
> transition the things that are sourcing /etc/init.d/functions.sh away from
> using that link.
> 
> eselect rc will be broken by default if OpenRc is removed, because it is an
> OpenRc specific module.
> 
> Another good reason for changing this canonical location is to allow
> non-OpenRc users to add /etc/init.d to INSTALL_MASK to block the
> installation of OpenRc scripts.

Refer back to comment 0 through about 6 ...  Why /lib/Gentoo?  First of all, the capital is intensely ugly.  Second, what's wrong with /lib64/rc/sh/functions.sh, its current location?

[Comment 119 Kirill Elagin 2014-02-08 19:38:11 UTC]

> what's wrong with /lib64/rc/sh/functions.sh, its current location?

Well, not exactly wrong, but the thing is: this file is used not only in RC but also in other tools with “Gentoo flavour”. So it might be better to avoid substring “rc”. `/lib/gentoo/functions.sh` seems fine.
That said, this is not on its own a good reason to move the file.

Personally I like the idea of having this file in `gentoo-functions` (or something similar) ebuild and leaving a compatibility symlink for some fixed period of time, say, 6 months. Or maybe better not a symlink but a copy with additional deprecation warnings.

[Comment 120 William Hubbs 2014-02-08 20:46:14 UTC]

(In reply to Kirill Elagin from comment #119)
> > what's wrong with /lib64/rc/sh/functions.sh, its current location?
> 
> Well, not exactly wrong, but the thing is: this file is used not only in RC
> but also in other tools with “Gentoo flavour”. So it might be better to
> avoid substring “rc”. `/lib/gentoo/functions.sh` seems fine.
> That said, this is not on its own a good reason to move the file.

The reason for creating the new file is for the Gentoo-flavor things that are not part of OpenRc. Anything that is part of OpenRc sources the correct file without using the /etc/init.d/functions.sh symlink, so we need a separate functions.sh for Gentoo things that are not part of OpenRc. This also allows us to get rid of the /etc/init.d/functions.sh symlink in the future by fixing the other Gentoo things to source the correct file directly.

[Comment 121 Ulrich Müller 2014-02-09 16:26:25 UTC]

(In reply to William Hubbs from comment #117)
> eselect rc will be broken by default if OpenRc is removed, because it is an
> OpenRc specific module.

As discussed on IRC:
http://git.overlays.gentoo.org/gitweb/?p=proj/eselect.git;a=commit;h=38614e63db2a5a124bc5971309c80c5c9533770e

[Comment 122 David Heidelberg (okias) 2014-02-14 21:58:56 UTC]

(In reply to Ulrich Müller from comment #121)
> As discussed on IRC:
> http://git.overlays.gentoo.org/gitweb/?p=proj/eselect.git;a=commit;
> h=38614e63db2a5a124bc5971309c80c5c9533770e

Great, what should be next move?

[Comment 123 Ulf Dambacher 2014-02-15 07:59:26 UTC]

I think there is a consensus on having a compartibility link in /etc/init.d/ .

1) decide if we need to have a "gentoo-script-lib" package to incorporate it together with other candidates if any or if functions.sh is a relict to be erased some time in future anyway.

2) we decide on the path where to put functions.sh replacement 
so we can set up some ebuilds 

3) finally if we find functions.sh should persist we need to argue about the minimal interface the file has to provide.

[Comment 124 Kirill Elagin 2014-02-15 08:39:24 UTC]

My view:

`functions.sh` should be split in two parts: OpenRC-specific (that is, packages that use those functions will have to explicitly depend on sys-apps/openrc) and “Gentoo stuff” which is useful without OpenRC (einfo, ewarn, etc.)

OpenRC-stuff stays in `/lib/rc/sh/` and belongs to sys-apps/openrc (obviously). Gentoo stuff goes to `/lib/gentoo/functions.sh` and belongs to a new ebuild gentoo-functions (in sys-apps or dev-libs…).

Instead of compatibility symlink in `/etc/init.d/` we put there a copy that does what it is expected to do _and additionally issues deprecation warnings_ saying that something is wrong and asking for a bug report. This compatibility script will be removed in 6 months.

This way we don't break any existing apps immediately, have useful diagnostic during transition and eventually get rid of openrc dependency for most packages.

[Comment 125 Samuli Suominen (RETIRED) 2014-02-15 09:08:14 UTC]

So, is anyone committing one of the discussed implementations? 
If not, I'll put efunctions-0.1.ebuild in tree that installs functions.sh to it's current location from the OpenRC tarball without anykind of modifications to the file, or location, and make the efunctions dependency of OpenRC
While leaving the bug open for enhancements which can go to 0.2 and to subsequent versions, of course
I'll give it a few days, in case someone is actually working on pushing something else to tree

[Comment 126 Ulf Dambacher 2014-02-15 09:27:51 UTC]

Please don't use the openrc paths so there is no path clash with openrc.
Also openrc does not need a new dependency as it comes with its own version.

You could go with the ebuilds I attached, maybe rename them apropriately.
I would step up to change them to our needs but I currently don't qualify as maintainer.

[Comment 127 Anthony Basile 2014-02-15 12:55:00 UTC]

(In reply to Ulf Dambacher from comment #126)
> Please don't use the openrc paths so there is no path clash with openrc.
> Also openrc does not need a new dependency as it comes with its own version.
> 

Or you can block against openrc.

[Comment 128 Pavel Volkov 2014-02-15 13:02:08 UTC]

(In reply to Anthony Basile from comment #127)
> Or you can block against openrc.

If you block, openrc wouldn't be able to co-exist with systemd on the same machine, would it?

[Comment 129 Samuli Suominen (RETIRED) 2014-02-15 13:25:02 UTC]

(In reply to Ulf Dambacher from comment #126)
> Please don't use the openrc paths so there is no path clash with openrc.
> Also openrc does not need a new dependency as it comes with its own version.
> 
> You could go with the ebuilds I attached, maybe rename them apropriately.
> I would step up to change them to our needs but I currently don't qualify as
> maintainer.

wrong, there is no problem whatsoever to remove file from package and then install it from another.

(In reply to Pavel Volkov from comment #128)
> (In reply to Anthony Basile from comment #127)
> > Or you can block against openrc.
> 
> If you block, openrc wouldn't be able to co-exist with systemd on the same
> machine, would it?

again, there is no problems whatsoever in moving a file from one package to another, and setting a revision based blocker for older version to avoid file collision. can be co-installed with whatever.

i'm ready to do the file move, i'm just waiting if the people who have worked on this bug and commented a lot want to commit their implementation, because i'll be just putting SRC_URI= same as openrc's SRC_URI= and directly install the functions.sh from the openrc tarball

[Comment 130 William Hubbs 2014-02-15 23:23:43 UTC]

(In reply to Samuli Suominen from comment #129)
> again, there is no problems whatsoever in moving a file from one package to
> another, and setting a revision based blocker for older version to avoid
> file collision. can be co-installed with whatever.
> 
> i'm ready to do the file move, i'm just waiting if the people who have
> worked on this bug and commented a lot want to commit their implementation,
> because i'll be just putting SRC_URI= same as openrc's SRC_URI= and directly
> install the functions.sh from the openrc tarball

Please do not do this. The functions.sh from the OpenRc tarball will not work because it requires the presence of the rc binary.

Iwill add my implementation by Thursday UTC (it is Sat now). I was just hoping that vapier would sign off on it since he was the one who was most vocal against it.

[Comment 131 Anthony Basile 2014-02-18 17:53:46 UTC]

(In reply to Pavel Volkov from comment #128)
> (In reply to Anthony Basile from comment #127)
> > Or you can block against openrc.
> 
> If you block, openrc wouldn't be able to co-exist with systemd on the same
> machine, would it?

Would you want it to?  But yeah, I guess you're right.

[Comment 132 William Hubbs 2014-02-20 05:11:58 UTC]

I wanted to give another quick update.

I got a request to get Service Supervision into OpenRc, so I  will get
this in the tree by Sunday UTC at the latest.

[Comment 133 David Heidelberg (okias) 2014-02-26 11:47:23 UTC]

(In reply to William Hubbs from comment #132)
> I wanted to give another quick update.
> 
> I got a request to get Service Supervision into OpenRc, so I  will get
> this in the tree by Sunday UTC at the latest.

Sunday passed, how it look? :)

[Comment 134 William Hubbs 2014-02-27 16:37:35 UTC]

Sorry it is taking longer than I thought, I have been working on bug
#501364 to add supervision to OpenRc.
Give me this next weekend. :-)

[Comment 135 William Hubbs 2014-02-27 16:46:11 UTC]

sorry about that.

[Comment 136 Alex Xu (Hello71) 2014-03-01 20:49:23 UTC]

e*dent don't actually use the default:

$ eindent
dash: 24: [: Illegal number: 

correct code:

[ 0"$i" -gt 0 ]

or:

[ "$i" ] && [ "$i" -gt 0 ]


[ -z "$1" ] && return 1

should be:

[ "$1" ] || return 1

esyslog:

if command -v logger >/dev/null 2>&1

return 0

is it really correct to return 0 if logger fails?

e*n are stubs; if they can't be implemented, don't implement them or print a warning

what is LAST CODE?

lots of "$*", questionable.

[Comment 137 Pavel Volkov 2014-03-03 10:56:01 UTC]

How is it going, William? :)

[Comment 138 William Hubbs 2014-03-04 05:16:34 UTC]

I will implement the changes suggested tomorrow and wait for more
comments.

[Comment 139 William Hubbs 2014-03-05 04:13:16 UTC]

(In reply to Alex Xu (Hello71) from comment #136)
> e*dent don't actually use the default:
> 
> $ eindent
> dash: 24: [: Illegal number: 
> 
> correct code:
> 
> [ 0"$i" -gt 0 ]
> 
> or:
> 
> [ "$i" ] && [ "$i" -gt 0 ]

I am using [ -n "$I" ] in place of [ "$I" ]; it seems more readable that way.

> 
> 
> [ -z "$1" ] && return 1
> 
> should be:
> 
> [ "$1" ] || return 1

Why? It seems like the test that is there is equivalent to yours.

> 
> esyslog:
> 
> if command -v logger >/dev/null 2>&1
> 
> return 0
> 
> is it really correct to return 0 if logger fails?

logger doesn't have any documented return codes we should check for.  Also, there isn't really any different action you can take if it does fail.

> 
> e*n are stubs; if they can't be implemented, don't implement them or print a
> warning

I would be cautious about messing with these too much since I don't know if anything that will need this script is calling them.

> 
> what is LAST CODE?

That just refers to the main part of the script.

> 
> lots of "$*", questionable.

Fill me in, why is this questionable? my update is going to be attached soon.

[Comment 140 William Hubbs 2014-03-05 04:28:41 UTC]

Created attachment 371754 [details]
functions.sh

Here is my latest functions.sh.

[Comment 141 Pavel Volkov 2014-03-05 10:09:47 UTC]

I tried the latest version.
"perl-cleaner --modules" prints endless errors:

/etc/init.d/functions.sh: line 34: [: : integer expression expected

[Comment 142 Thomas Deutschmann (RETIRED) 2014-03-05 10:47:56 UTC]

(In reply to William Hubbs from comment #139)
> (In reply to Alex Xu (Hello71) from comment #136)
> > esyslog:
> > 
> > if command -v logger >/dev/null 2>&1
> > 
> > return 0
> > 
> > is it really correct to return 0 if logger fails?
> 
> logger doesn't have any documented return codes we should check for.  Also,
> there isn't really any different action you can take if it does fail.

Wrong?

From `man logger`:

  > The logger utility exits 0 on success, and >0 if an error occurs.

So you can check logger's return message. But the question should be: What do you expect from this check:

If you don't have a running syslogger, logger still returns 0 (SUCCESS). So if you want to use this check to make sure that the message was really received from your syslogger, you can't.

But if you want to use this check as a kind of syntax check, e.g. we could have a problem in the code or future logger versions may change their syntax... then checking the return value make sense. Without this check we won't notice that our logger calls don't succeed anymore.

[Comment 143 Alex Xu (Hello71) 2014-03-05 12:26:05 UTC]

(In reply to William Hubbs from comment #139)
> (In reply to Alex Xu (Hello71) from comment #136)
> 
> I am using [ -n "$I" ] in place of [ "$I" ]; it seems more readable that way.
>

Sounds good.

> > [ -z "$1" ] && return 1
> > 
> > should be:
> > 
> > [ "$1" ] || return 1
> 
> Why? It seems like the test that is there is equivalent to yours.
>

It's shorter. :)

> > 
> > esyslog:
> > 
> > if command -v logger >/dev/null 2>&1
> > 
> > return 0
> > 
> > is it really correct to return 0 if logger fails?
> 
> logger doesn't have any documented return codes we should check for.  Also,
> there isn't really any different action you can take if it does fail.

See below.

> > 
> > e*n are stubs; if they can't be implemented, don't implement them or print a
> > warning
> 
> I would be cautious about messing with these too much since I don't know if
> anything that will need this script is calling them.

If they are supposed to be stubs, great. Comment them and explain why.

If they aren't, then scripts using them will break anyways. Better print a warning why or fix them.

> > 
> > what is LAST CODE?
> 
> That just refers to the main part of the script.

Perhaps a better comment: INIT CODE or something like that.

> > 
> > lots of "$*", questionable.
> 
> Fill me in, why is this questionable? my update is going to be attached soon.

Generally, "$*" can be replaced with "$@", but I haven't studied the script too closely.

(In reply to Thomas D. from comment #142)
> (In reply to William Hubbs from comment #139)
> > (In reply to Alex Xu (Hello71) from comment #136)
> > > esyslog:
> > > 
> > > if command -v logger >/dev/null 2>&1
> > > 
> > > return 0
> > > 
> > > is it really correct to return 0 if logger fails?
> > 
> > logger doesn't have any documented return codes we should check for.  Also,
> > there isn't really any different action you can take if it does fail.
> 
> Wrong?
> 
> From `man logger`:
> 
>   > The logger utility exits 0 on success, and >0 if an error occurs.
> 
> So you can check logger's return message. But the question should be: What
> do you expect from this check:
> 
> If you don't have a running syslogger, logger still returns 0 (SUCCESS). So
> if you want to use this check to make sure that the message was really
> received from your syslogger, you can't.
> 
> But if you want to use this check as a kind of syntax check, e.g. we could
> have a problem in the code or future logger versions may change their
> syntax... then checking the return value make sense. Without this check we
> won't notice that our logger calls don't succeed anymore.

More error checking is usually better than less, especially when it's almost free.

Also, in future versions, perhaps logger will do more error checking.

[Comment 144 Alex Xu (Hello71) 2014-03-05 12:27:42 UTC]

(In reply to William Hubbs from comment #140)
> Created attachment 371754 [details]
> functions.sh
> 
> Here is my latest functions.sh.

You only changed one.

if i is empty, [ "$i" -lt 0 ] expands to [ -lt 0 ] which is obviously invalid.

[Comment 145 William Hubbs 2014-03-05 18:05:38 UTC]

(In reply to Thomas D. from comment #142)
> (In reply to William Hubbs from comment #139)
> > (In reply to Alex Xu (Hello71) from comment #136)
> > > esyslog:
> > > 
> > > if command -v logger >/dev/null 2>&1
> > > 
> > > return 0
> > > 
> > > is it really correct to return 0 if logger fails?
> > 
> > logger doesn't have any documented return codes we should check for.  Also,
> > there isn't really any different action you can take if it does fail.
> 
> Wrong?
> 
> From `man logger`:
> 
>   > The logger utility exits 0 on success, and >0 if an error occurs.

My search string was "returns" instead of "exits"; that is why I didn't see  this in the man page.

> 
> So you can check logger's return message. But the question should be: What
> do you expect from this check:
> 
> If you don't have a running syslogger, logger still returns 0 (SUCCESS). So
> if you want to use this check to make sure that the message was really
> received from your syslogger, you can't.

That seems to be because syslog(3) does not return an error if you can't communicate with a syslogger. Actually none of the functions listed on that man page return error codes.

> But if you want to use this check as a kind of syntax check, e.g. we could
> have a problem in the code or future logger versions may change their
> syntax... then checking the return value make sense. Without this check we
> won't notice that our logger calls don't succeed anymore.

If the syntax of the logger command changes in an incompatible way , more than likely, the logger calls would display error messages, and this script would have to be fixed, but not the consumers that call the esyslog function. I think the likelihood of upstream breaking the logger command in this way is probably pretty low.

[Comment 146 Boney McCracker 2014-03-05 19:17:45 UTC]

William,

I admire your patience with Alex's sophomoric critique of your code.

Thank you for moving this forward.

After you have addressed Paul's issue, what can people do to help you with testing?

[Comment 147 Alex Xu (Hello71) 2014-03-05 22:02:08 UTC]

(In reply to BoneKracker from comment #146)
> William,
> 
> I admire your patience with Alex's sophomoric critique of your code.

Ouch. It's not like I'm trying to help improve a script that's going to be installed on somewhere between "a significant proportion" and "every" Gentoo system in the world so that it *actually works on those systems*.

[Comment 148 Tom Wijsman (TomWij) (RETIRED) 2014-03-05 23:32:32 UTC]

Good point; given that, it might be wise to pass this by gentoo-dev for review.

[Comment 149 William Hubbs 2014-03-06 06:49:33 UTC]

Created attachment 371834 [details]
functions.sh

This is the latest version. Let me know what you think.

To answer questions about how this will work, once we have an ebuild,
the script will be installed in /lib/gentoo/functions.sh, then packages
that source /etc/init.d/functions.sh will need to be changed to source
/lib/gentoo/functions.sh instead, so testing will take coordination, so
yes I will need to go to gentoo-dev to figure that out.

[Comment 150 Ulf Dambacher 2014-03-06 08:24:01 UTC]

I wrote the ebuild for william's functions.sh, you can look at my overlay at
https://github.com/ulda/gentoo-ulda

and I tested it: 
found some problem with color codes

# gcc-config  -l
 [1] x86_64-pc-linux-gnu-4.7.3 \033[32;01m*\033[0m
# gcc-config  -C -l
 [1] x86_64-pc-linux-gnu-4.7.3 \033[32;01m*\033[0m

have you seen https://github.com/marcusatbang/efunction ?

especially how he handles color:
https://github.com/marcusatbang/efunctions/blob/master/efunctions/eval_ecolors

[Comment 151 Ulf Dambacher 2014-03-06 08:25:21 UTC]

Created attachment 371842 [details]
ebuild for william's functions.sh

place functions.sh from attachments to files dir

[Comment 152 Ulf Dambacher 2014-03-06 09:15:59 UTC]

gcc-config and binutils-config are broken - they don't use pritnf or echo -e...

[Comment 153 Ulf Dambacher 2014-03-06 09:51:32 UTC]

comments please:  would you prefer that

A) we install a link in /etc/init.d/functions.sh and don't say anything

B) we install a script there that prints a warning like this:
     #!/bin/bash
     source /lib/gentoo/functions.sh
     ewarn "This script sources /etc/init.d/functions.sh,\
     please file a bug about this"

[Comment 154 Pavel Volkov 2014-03-06 10:15:58 UTC]

(In reply to Ulf Dambacher from comment #153)

I'd prefer B for a couple of months and then exterminate /etc/init.d/functions.sh

[Comment 155 William Hubbs 2014-03-06 16:13:13 UTC]

This package will be installed on every gentoo system, so we can't block
OpenRc in the ebuild as suggested in comment #151.

There are two questions I need to figure out answers for from
gentoo-dev.

1) how to handle the symbolic link in /etc/init.d/functions.sh.
This is owned by OpenRc and should probably stay so until it is
deprecated, so we can't really mess with it in gentoo-functions.

2) How to handle the RC_NOCOLOR variable.
On OpenRc systems, this can be set in /etc/rc.conf if you do not want
to have color in the output, but there is no place to set it for
non-OpenRc systems. Is one variable enough to justify a configuration
file of our own?

[Comment 156 Paul Varner (RETIRED) 2014-03-06 16:44:31 UTC]

revdep-rebuild.sh has been updated to prefer /lib/gentoo/functions.sh over /etc/init.d/functions.sh.

http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=commit;h=11cc48f031c017e8746109a9a28782085e2d1292

People can use gentoolkit-9999 to test these changes.

[Comment 157 William Hubbs 2014-03-10 05:23:07 UTC]

All,

I will be commiting gentoo-functions to the tree within the next 24
hours. At that point we can close this bug and start fixing the
other consumers the same way gentoolkit was fixed.

[Comment 158 Ulf Dambacher 2014-03-10 06:31:04 UTC]

@william: How do you want to solve your two questions from comment 155

[Comment 159 Kirill Elagin 2014-03-10 08:42:25 UTC]

(In reply to William Hubbs from comment #155)
> 1) how to handle the symbolic link in /etc/init.d/functions.sh.
> This is owned by OpenRc and should probably stay so until it is
> deprecated, so we can't really mess with it in gentoo-functions.

Isn't this _already_ deprecated?

> 2) How to handle the RC_NOCOLOR variable.
> On OpenRc systems, this can be set in /etc/rc.conf if you do not want
> to have color in the output, but there is no place to set it for
> non-OpenRc systems. Is one variable enough to justify a configuration
> file of our own?

Anyway this variable only matters in user terminals (there is no color when there is no tty attached, right?), so those who don't want colors can just export this for their sessions. Or, if they really don't like colors, have it in /etc/env.d/.

[Comment 160 William Hubbs 2014-03-10 15:15:57 UTC]

(In reply to Kirill Elagin from comment #159)
> (In reply to William Hubbs from comment #155)
> > 1) how to handle the symbolic link in /etc/init.d/functions.sh.
> > This is owned by OpenRc and should probably stay so until it is
> > deprecated, so we can't really mess with it in gentoo-functions.
> 
> Isn't this _already_ deprecated?

It is, and I have determined a way to handle it within OpenRc.
/etc/init.d/functions.sh will become a script that sources /lib/rc/functions.sh and outputs a warning. It will stay that way until OpenRc-1.0 when it will be removed.

> > 2) How to handle the RC_NOCOLOR variable.
> > On OpenRc systems, this can be set in /etc/rc.conf if you do not want
> > to have color in the output, but there is no place to set it for
> > non-OpenRc systems. Is one variable enough to justify a configuration
> > file of our own?
> 
> Anyway this variable only matters in user terminals (there is no color when
> there is no tty attached, right?), so those who don't want colors can just
> export this for their sessions. Or, if they really don't like colors, have
> it in /etc/env.d/.

Yes, that should take care of it, and that is the way I will go for this script since no one on Gentoo-dev mentioned anything else.

[Comment 161 Sorrow 2014-03-10 18:40:04 UTC]

William, I have tried your functions.sh from #149 and have the same problem with colors, as Ulf reported in 150.

[Comment 162 Kirill Elagin 2014-03-10 20:05:33 UTC]

Created attachment 372314 [details, diff]
Proper colors

I also confirm this colors thing.

Here is the issue: some tools (e.g. `gcc-config`) source function.sh and then use variables defined there with `echo`. This doesn't work now, because they call echo without `-e`, so escape sequences are not interpreted.

I suggest using termcap for this, falling back to hardcoded escape sequences. That's what OpenRC does, as far as I can tell.

[Comment 163 William Hubbs 2014-03-10 20:05:37 UTC]

gentoo-functions has been added to portage. Bug #504116 is the tracker for updating packages to take advantage of it.

[Comment 164 David Heidelberg (okias) 2014-03-10 20:12:36 UTC]

Great work, thank you William & all involved! :)

[Comment 165 Kirill Elagin 2014-03-10 20:21:15 UTC]

Created attachment 372318 [details, diff]
Even more proper colors

I've just checked the link from #150.

[Comment 166 William Hubbs 2014-03-10 20:43:34 UTC]

(In reply to Kirill Elagin from comment #165)
> Created attachment 372318 [details, diff] [details, diff]
> Even more proper colors
> 
> I've just checked the link from #150.

Can you please open a separate bug for this, and explain the problem and provide the attachment there?

This bug is getting really long, and the functions are now in the tree.
I'm not ignoring this, I'm just not sure what the problem is, and I think we should put this on its own bug.

[Comment 167 Kirill Elagin 2014-03-10 20:53:46 UTC]

(In reply to William Hubbs from comment #166)
> Can you please open a separate bug for this, and explain the problem and
> provide the attachment there?

Bug 504138.

[Comment 168 Kirill Elagin 2014-03-11 17:59:11 UTC]

(In reply to William Hubbs from comment #160)
> It is, and I have determined a way to handle it within OpenRc.
> /etc/init.d/functions.sh will become a script that sources
> /lib/rc/functions.sh and outputs a warning. It will stay that way until
> OpenRc-1.0 when it will be removed.

Could we move /etc/init.d/functions.sh proxy to gentoo-functions?
I mean, yes, it's weird that gentoo-functions will own a file in /etc/init.d/ but all this is crazy enough already (shell library in /etc/init.d/). This will make it possible to unmerge OpenRC before /etc/init.d/functions.sh is completly dropped (how long will it take, half a year?) but before all the consumers are fixed.

[Comment 169 Tom Wijsman (TomWij) (RETIRED) 2014-05-03 17:49:05 UTC]

*** Bug 509488 has been marked as a duplicate of this bug. ***

[Comment 170 hexum 2014-05-11 07:26:48 UTC]

This bug is still actual! How to reopen it?
Package sys-apps/gentoo-functions doesn't provide file /etc/init.d/functions.sh
OpenRC is still part of systemd-based profiles!

[Comment 171 Benedikt Böhm 2014-05-11 07:31:20 UTC]

you should follow bug #504116