[Toybox] Toybox Installer/setup routine?

[Rob Landley]

On 9/2/19 6:10 PM, Denys Nykula wrote:
>>> which awk 2>&1 >/dev/null || ln -fsv nawk /bin/awk
>>> which vi 2>&1 >/dev/null || ln -fsv vim /bin/vi
>>
>> Those last two are on the todo list. But after toysh and route, which mkroot
>> needs. (And vi might be after make, and promoting half the stuff currently in
>> pending.)
> 
> Implementing sh and make would definitely be most useful, as nobody has yet
> written light build tools ready to drop in place of GNU monopoly.

I was working on it, https://landley.net/code/tinycc and
https://landley.net/code/qcc but I hit the problem that gcc rewrote itself in
c++ and llvm is c++ and I'd need a new cfront. But now there's the llvm c
backend, so I should start working on that again. But not _just_ now...

> The weakest
> bootstrap link would next be a subset of cmake interpreter enough to build
> LLVM. While existing awks and editors with simple license are okay.

It's probably easier to maintain a makefile for llvm, cmake is terrible.
Although as long as you can build the existing cmake with the existing tools we
don't have to care...

Once upon a time I wrote a long 2 part rant about what I think needs to be done
for configure/make/install:

http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000859.html
http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000860.html

Unfortunately I dunno what the design of a make replacement looks like. There
were a bunch of cvs/bazaar/perforce variants before we got git, all of which
were basically "CVS but different" rather than the actual fundamental rethink of
the space. Sadly, have yet to see a build variant that _isn't_ a make version of
SVN rather than a make version of git.

>>> Since I symlink `/sbin` to `bin` and `/usr` to `.`,
>>
>> I go the other way with /usr (symlink the top level bin/sbin/lib into usr)
>> because I don't want more debris (include, local, share...) at the top level.
> 
> Most do the classic usrmerge

As far as I can tell I invented the classic usr merge, and when Red Hat started
doing it they cited me. :)

https://www.linuxfoundation.org/blog/2012/01/the-ever-changing-linux-filesystems-merging-directoris-into-usr/

> but hierarchies are my pet peeve, and the
> reversal seems slightly less complex with fewer total links.

If you don't mind /share and /include at the top level.

My mkroot script creates a minimal directory hierarchy (enough to install linux
from scratch into) in 3 lines:

mkdir -p "$ROOT"/{etc,tmp,proc,sys,dev,home,mnt,root,usr/{bin,sbin,lib},var} &&
chmod a+rwxt "$ROOT"/tmp && ln -s usr/{bin,sbin,lib} "$ROOT" || exit 1

>>> for i in head ifconfig route sed; do ln -fsv busybox /bin/$i; done
>>
>> What do you need head, ifconfig or sed for? (What is the toybox version missing
>> and/or getting wrong?)
> 
> Head with negative -n value is used in Linux kernel build for atomics checks,

Huh, what architecture/config requires this? (I've been building the kernel with
toybox for years now, and built it with mkroot yesterday. Didn't see this. The
only thing I'm finding with grep isn't building the kernel, it's building perf:

tools/perf/tests/shell/record+zstd_comp_decomp.sh:
$perf_tool report -i $trace_file --stdio | head -n -3 > $trace_file.comp.output &&

But if you tell me you need things, I can add them.

> it prints all except last few lines. Ifconfig and route didn't work against a
> pizza place Wi-Fi for unknown reason,

"Unknown reason". Ok, happy to leave it unfixed then...

> busybox was okay there. For sed
> I have in my notes this line from some Portage script:
> 
> if ! sed -n -e '/^# Generated by .*libtool/q0;4q1' "${f}"; then continue; fi

Ok, so you need the exitcode extension to q, and never previously mentioned it
on this list. Right, easy enough to add...

> Libtool is supposed to help with portability, but portability in GNU speak
> means nothing builds unless you run GNU, and distro maintainers use some
> tricks with even more GNU dependency to unbreak some of the problems
> libtool creates.

Libtools' original purpose was to make non-ELF systems behave like ELF. When
Linux switched to ELF in 1996 they found other random crap for it to do. It
serves zero purpose, and somebody has a libtools replacement over on the musl
mailing list for the other random crap it shouldn't be doing.

Me, I never install it. Anything gnu should detect that it's not there via
autoconf and bypass it, and anything non-gnu is too dumb to live if it's using
it in the first place..

> There are also patch -f and find -newerXY but these are both tricky and
> unimportant compared to bootstrap tools.

The busybox patch.c _is_ the toybox patch.c. I sent them my patch circa 2010,
and updated it a few times for them.

What use cases need those?

Let's see, we don't check "Prereq:" lines, I don't remember implementing
querying /dev/tty for a filename if the one in the patch isn't there (we just
fail), and although we _warn_ about possibly reversed patches that's all we do.
So our current behavior _is_ -f already, and it sounds like I should
accept-but-ignore the option?

Um, looking at newerXY... there are only 3 times in stat, create, access,
modification. What's this "birth" nonsense? Why is Hurd tracking that
differently then linux, and why would anyone care? (Would making b and c
synonyms break anything?)

I can see -newermt 123456789 being useful, though...

>> As long as it doesn't dereference the symlink and stomp the binary at its end.
>> (The bzip2 installer used to do that to busybox. THAT was a fun one to debug.
>> And this is why the "install" command has different defaults than the "cp"
>> command. :)
> 
> Portage seems careful with symlinks, but I have fun with each GCC install
> silently removing llvm-libunwind and no obvious line to blame for this.

The FSF is terrible at writing software. They always were. The existence of
autoconf and libtool and such is overcompensation: they really really really
suck at this, to the point they had to create giant piles of overengineered crap
to do it _badly_. And then tout how much _effort_ they spent crapping that out
as a sign "you don't want to go through all that labor we went through".

No. No we don't. That doesn't mean we want to get your steaming pile on us either.

https://www.kernel.org/doc/html/v4.10/process/coding-style.html still says:

> First off, I’d suggest printing out a copy of the GNU coding standards, and
> NOT read it. Burn them, it’s a great symbolic gesture.

It's said that for a quarter century now, and it's still true.

Rob