[Toybox] toybox symlink paths, OE conventions and FHS

[enh]

On Mon, Dec 10, 2018, 05:39 Eduardas Meile <eduardas.m at fods.com 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.
>
> 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.
>
> Also noticed that sed, dd and ps should go into /bin according to the
> FHS spec hosted by the Linux Foundation:
>
> 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.
>
> 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. If it does
> not adhere to some specific spec,
>
> perhaps it follows how some specific distro (or Android) does this?
>

Android puts everything in one directory, because there's no need for more
than one :-)

our one directory is /system/bin for similar historical reasons to the Unix
/ vs /usr mess, but on the latest devices that's actually obsolete and
we've been cleaning it up (or making things worse, depending on your point
of view) by adding symlinks like /bin and /etc.

but we don't use the toybox annotations at all: our build system has a list
of the toy symlinks it should generate, and it generates them all in
/system/bin. so we're not affected by any of this.

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
>
> 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.
>
> 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?
>
>
>
>
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20181210/8f1961f7/attachment-0001.htm>