[OE-core] [PATCH 2/8] initscripts: add setup-commands.sh

[Phil Blundell]

On Mon, 2013-11-11 at 10:52 +0800, ChenQi wrote:
> On 11/10/2013 07:00 AM, Phil Blundell wrote:
> > 1. initscript doesn't obviously rdepend on busybox so it's not obvious
> > that the latter will always be available;
> 
> Yes. Initscript doesn't rdepend on busybox. But note it also doesn't
> rdepend on sed or awk or grep.
> So I think it's reasonable to assume the presence of busybox.

I think one could argue that it's also a bug that it doesn't rdepend on
the three things you mentioned (and indeed on /bin/sh itself, for
non-rpm systems).  However, the usage of grep and sed in particular, and
perhaps to a slightly lesser extent awk, is so deeply ingrained into so
much software that I think it's probably fair to say those utilities
will almost always be present.

By contrast, it is perfectly feasible to build a system which doesn't
use busybox (by using the full GNU implementations of everything that
busybox provides) and indeed I think there might even be a task package
in oe-core which does exactly that.  So it seems entirely possible
that /bin/busybox might not be installed unless you have a dependency on
it.

> > 2. it should probably be using ${base_bindir} and ${bindir} rather than
> > hardcoding absolute paths.
> 
> In init scripts, we usually "hardcode" things, because these scripts
> are destined to run on target.
> In recipes we try not to hardcode things because the recipe may need
> to extend to "native" or "nativesdk".

I'm not quite sure I follow the logic here.  Even if the script is
intended to run on the target it still ought to be respecting the values
of ${bindir}, ${sysconfdir} and such like.

> > 3. the whole idea of creating a shadow "/usr/bin" underneath what's
> > meant to be a mountpoint seems rather dubious to me. 
> 
> Agree.
> 
> The problem here is that the init scripts under /etc/rcS.d/ need to
> execute commands like awk, dirname, and readlink which are from /usr. 
> 
> As it's not appropriate to move these commands into /bin, basically
> there are only two options I can see here. One is to modify these
> scripts to use only commands from /bin or /sbin; the other is to make
> use of busybox, as busybox is located under /bin as it provides these
> commands. 
> I chose to the latter one because I thought that solution would have
> the less impact. 
> 
> What do you think? Do we need to modify the init scripts? Or any other
> solution? 

I thought that last time this topic came up on the mailing list, the
eventual conclusion was that Wind River (being more-or-less the only
people who seemed to feel strongly that supporting / and /usr on
different partitions was important) were going to come up with some sort
of overall strategy for solving the whole problem rather than just
fixing up individual bits in a piecemeal fashion.  I think that strategy
would need to include a policy for which utilities initscripts can
legitimately expect to be available before /usr is mounted, and if this
set is different from what we have today then it would need to include a
plan for sorting that out.

To answer the particular question at hand it seems that someone would
need to do some analysis of things like:

- how many scripts actually need those commands
- how hard would it be to change them to not need them
- what would be the impact of moving them into ${base_bindir} (for
example, would this cause a whole load of libraries to get dragged into
${base_libdir} as well?)

Offhand I don't know the answer to any of those things.

> > 4. this seems like distro policy and not something that really belongs
> > in oe-core at all.  For systems where ${bindir} and ${base_bindir} are
> > on the same filesystem (or even are the same directory) this script will
> > just make bootup slower without achieving anything useful.

> If /usr and / are on the same file system, this script has no real
> effect because /usr will always be there. So I think it will not take
> much time at boot.

Just spawning a new copy of the shell and reading the script does take a
finite (and measureable) time.  If you can determine statically at build
time that the script isn't going to do anything useful then I don't
think it's appropriate to install it.

> If ${base_bindir} and ${bindir} are the same, that means that there's
> no /usr. In this case, there should no /usr/xxx entries
> in /etc/busybox.links, so this script should also function correctly
> and it will not take much time at boot.
> 
> (I just configured ${bindir} and ${base_bindir} to be the same and
> performed a build, it failed. I'm not sure whether it's valid to make
> such configurations in OE.)

It is a valid configuration, and this is the way that most of the images
I build are configured.  It probably is true that there are still some
number of recipes in oe-core that don't support this properly, but I
don't want to see that situation get any worse.

p.