Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)

[Mike Frysinger]

On Monday 08 June 2009 19:23:01 Robin H. Johnson wrote:
> On Mon, Jun 08, 2009 at 07:27:02AM -0400, Mike Frysinger wrote:
> > > >> Also, should Gentoo (Linux) never break with tradition even if
> > > >> somethings are better elsewhere?
> > > >
> > > > no, there is no "innovation" here nor any incentive to do so.  i also
> > > > personally dont believe in /usr/libexec/, so i'm not going to
> > > > randomly be convinced by /libexec/ in the meantime.
> > >
> > > The "innovation" here being shell scripts and text files are not 32/64
> > > bit dependent and thus don't belong in a directory clearly marked as
> > > such.
> >
> > ABI is really not the driving force behind libexec vs lib, nor does it
> > really matter here.  openrc isnt a multilib package nor does it need to
> > be.
>
> Even while it isn't a multilib package, there's precedent to move stuff
> out of /lib (/usr/lib etc).

not really.  the precedent is to move from / to /usr.  we havent really cared 
about anything else (ignoring correctness of moving state files to /var).

> One of the reasons to move stuff OUT of /lib are all the profiles where
> SYMLINK_LIB is disabled AND LIBDIR_${arch} != "lib". On non-multilib
> systems (so there is no lib23/64) or multilib systems where /lib is the
> correct location, then any test against /lib/rc/version would be fine.
> On anything else, it's not.
>
> Having it in a different location from upstream (OpenRC), means that any
> other distributions using OpenRC's /libexec/rc/version location would
> need to patch all their init.d scripts.

the proposed /sbin/functions.sh check would makes this issue moot

> vapier: I take it by this entire discussion that you aren't going take
> the rest of OpenRC's move of scripts to /libexec either?

ive already added that change to the openrc-9999 to keep things in /lib/rc/
-mike