[Toybox] toybox symlink paths, OE conventions and FHS

[Rob Landley]

It has come to my attention that toybox is currently patched to change paths of
http://cgit.openembedded.org/meta-openembedded/commit/meta-oe/recipes-core/toybox/toybox/OE-path-changes.patch?id=cdd3e9ab99d4ffda673b564ba802b6bd2d40eabf
Not really sure which project does the right thing: OE or toybox.

This came up before... Ah, you spoted it.

Also, I have noticed that there was a thread on the mailing list discussing
http://lists.landley.net/htdig.cgi/toybox-landley.net/2015-April/007262.html
http://lists.landley.net/pipermail/toybox-landley.net/attachments/20150410/56dd947d/attachment-0004.patch
http://lists.landley.net/htdig.cgi/toybox-landley.net/2015-April/007262.html
Not sure why but some of the suggested changes for paths (like the ones for sed,
dd and ps) were never implemented.

Way back when I wrote a thing:

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Which attracted attention:

http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

Which influenced people (as in they linked to my writeup):

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

Which was admittedly controversial:

https://rusty.ozlabs.org/?p=236

But it snowballed and is still going on:

https://lwn.net/Articles/773342/rss

That's probably the main reason it fell through the cracks?

That said, looking at the patch some of the changes seem to be about moving
between bin and sbin, not just /bin vs /usr/bin. When I add a command I
generally go "which command" to see where ubuntu puts it, and put it there, but
they've moved stuff in later releases a couple times...

Also noticed that sed, dd and ps should go into /bin according to the FHS spec

That sounds like the /usr merge again.

The Linux Foundation's kinda flamingoed up its standardization duties:

http://landley.net/notes-2010.html#18-07-2010

https://lwn.net/Articles/658809/

http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s04.html
So that raises the question whether toybox tries to follow the Linux Foundation
FHS spec.

Not really, no.

http://landley.net/notes-2017.html#24-12-2017

As it is not listed among "Relevant Standards" on
http://landley.net/toybox/about.html
I assume it does not, but a clarification would be very welcome. It is unclear
to me personally what is the driving force behind how toybox sets tool symlinks.

"Where Ubuntu put it when I checked", "Who has complained", and "Did some
package's build script break?"

Last I checked Android was installing all the toybox binaries it builds into
/system/bin, and I didn't find anything that broke building the Linux From
Scratch packages (and a chunk of BLFS) under aboriginal linux (but that was
symlinking /bin to /usr/bin back in like 2003, so...)

If it does not adhere to some specific spec,
perhaps it follows how some specific distro (or Android) does this?

"Where it was in ubuntu when I added it", although I could easily have made
mistakes. And that also means some of these I was checking ubuntu 06.06 and some
ubuntu 08.04 and so on...

should I ask for changes in default toybox tool paths (like people did back in
2015) or patching the paths in OE

Sigh, let's see...

microcom is /bin -> /usr/bin

That's the /usr merge thing, I don't personally care either way?

blockdev is /usr/bin -> /sbin

Toybox blockdev works just fine as a normal user? You tend to want it to see if
blah.img is vfat or squashfs or what before feeding it into qemu? (Logically,
blockdev should be part of the "file" command, which is in /usr/bin on ubuntu
14.04...)

chrt is /usr/sbin -> /usr/bin

Modern ubuntu agrees with you.

hwclock /usr/bin -> /sbin

Sure.

modinfo /bin -> /sbin

Ok.

pmap /bin -> /usr/bin

/usr merge again, but as long as we've still got the flags...

printenv /usr/bin -> /bin

/usr merge

taskset /bin -> /usr/bin
timeout /bin -> /usr/bin
timeout /bin -> /usr/bin
nice /usr/bin -> /bin

and the rest of it is all adding or removing /usr

None of those really make any difference to me? I don't have a reason _not_ to
merge the patch?

is the correct solution? The patch appeared relatively recently. The reason
 <rburton> (mostly because there was a bug in update-alternatives until about a
week ago where it didn't like alternatives for commands being in different
directories
If patching in OE is the correct path, the patch should probably be extended to
cover all of the toybox tools, not just the ones in the default defconfig.

The stuff in defconfig is finished. The stuff in pending isn't recommended for
general consumption (although Android's fished a half-dozen things out of there
and I really should finish reviewing and cleaning that stuff up and promoting it
out of pending).

https://github.com/landley/toybox/blob/master/toys/pending/README

Busybox in OE does not need any patches for paths as far as I can tell, so
perhaps it would be a good idea for toybox to install
things where busybox installs them?

I don't have any strong objections. Anybody else here want to speak up?

Rob