Re: [gentoo-dev] gentoo-functions is in the tree

[William Hubbs]

On Tue, Mar 11, 2014 at 10:10:42AM -0400, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 10/03/14 07:30 PM, William Hubbs wrote:
> > All,
> >
> > for bug 373219 [1], we are working on providing a functions.sh that
> > does not rely on OpenRc so that people who are not using OpenRc
> > can completely remove it from their systems.
> >
> > I can now report that gentoo-functions has been added to the tree.
> > Also, I have opened a tracker [2] that explains how to change
> > packages that source /etc/init.d/functions.sh. They should first
> > check for the existence of /lib/gentoo/functions.sh and source
> > that. If it doesn't exist, they should source
> > /etc/init.d/functions.sh. Also, do not add hard dependencies to
> > your packages on gentoo-functions. The goal is to add
> > gentoo-functions to @system once it is stable.
> >
> > The quickest way to find things that will need this fix is to rm
> > /etc/init.d/functions.sh and file bugs against things that break
> > and make them block the tracker.
> >
>
> - From what I remember about conversations on this in the past, and
> hopefully vapier can confirm, the de-facto location for this script is
> supposed to be /etc/init.d/functions.sh.  Was there a general
> consensus on the approval of that location change?  I still think, at
> worst, we should ensure the gentoo-functions script installs a symlink
> here (possibly taking over the one installed by openrc, if openrc
> still installs one)

This was discussed at length on the bug. After multiple people presented
arguments supporting changing this location, vapier was given ample time
to weigh in with reasons that we shouldn't change it. He did not, so it
has been changed [1].

No, I don't think gentoo-functions should take over the symbolic link in
/etc/init.d/functions.sh; that needs to stay with OpenRc. My plan there
is to work that into a script that prints a warning message. It will
stay that way until openrc-1.0. OpenRc upstream uses semantic
versioning [2]. This means that as long as we are at 0.x we have to
keep things backward compatible.

> Also, just to confirm, this new path is compatible with the einfo
> package used as part of Prefix, yes?  Or other arrangements have been
> made (ie, the einfo package will be dropped from baselayout-prefix)?

No one has said anything to me about prefix so I don't know what they
want to do. To be honest I would prefer that they drop einfo. unless
there is a good reason for them not to.

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=373219
[2] http://www.semver.org