On 12/10/18 7:39 AM, Eduardas Meile wrote: > It has come to my attention that toybox is currently patched to change paths > of > some tools in Open Embedded: > > 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 > similar issues back in 2015: > > 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 > > The end of the thread is inconclusive: > > 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 > hosted by the Linux Foundation: 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... > My main concern here is to understand what the proper technical solution > should be: > > 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 > (from Yocto IRC): > > <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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
