On 9/2/19 5:43 PM, scsijon wrote: > On 03/09/19 07:50, Rob Landley wrote: >> >> >> On 9/1/19 6:22 PM, scsijon wrote: >>> This may be a can of worms or off-topic but... >>> >>> I was wondering if Toybox should/could have an inbuilt installer/setup >>> routine >>> of some sort and how are others handling this retro-fit problem! >> >> "When I download toybox as a normal user, it doesn't run as root. I don't >> have >> the root password. Toybox should include some sort of installer to give me >> root >> access when run as a normal user." > > N o, i'm coming from Linux in general, not android specific, also the version > I > use (puppylinux) is the user as root.
Ah. We already have infrastructure for that, the toybox --help output includes: To install command symlinks, try: for i in $(/bin/toybox --long); do ln -s /bin/toybox $i; done And people have successfully used that, which is why commit b8070a742549 adjusted some of those locations because openembedded's plumbing cared. (Which configuring alternatives, the alternatives had to live in the same place.) >> Just install into $HOME/toybox and add that to the start of the $PATH? Those >> commands would then be found first. > > A possability, but it doesn't follow what were doing now with commands, where > their either in /bin or /usr/bin, I am very reluctant to be forced to do this > as > I don't want to change the current process procedures we all use for just one > package. Toybox has had "make install" and "make install_flat" targets since the beginning. At runtime toybox --help has a one liner you can cut and paste to install into paths if you have root. I just added a second oneliner to install everything in the same subdirectory, which I hadn't before because I thought it was too obvious? The infrastructure I added was "if you run toybox with no arguments, you get the command names in a format suitable for consumption by for or while read, and toybox --long gives you the paths to install them at". Then it's not _my_ decision whether that's hardlinks or softlinks or what. >>> I'm not sure it's that hard, as I think it would be mainly renaming busybox >>> links to -BB and full commands to -FULL when doing the install routine as >>> far as >>> the linux community is concerned, and i'm sure enh and others will be able >>> to >>> comment with equivalents relative to the macOS, android, ASOP and other >>> systems >>> your installed into (like that ibm-fuji maintenance timeslot). >> >> If somebody wants to make an installer for new toybox versions, have at. >> (Although the above "install somewhere and put it at the start of the $PATH" >> seems obvious for everything except /bin/sh?) P.S. See "somebody wrote an installer that dealt with alternative versions", above. I submitted a patch to buildroot to add toybox and the reason I haven't resubmitted is busybox has giant if/then staircases for what it's an "alternative" to threaded throughout their installer. That's two seperate build systems that need extensive infrastructure for that, and have a todo item to add it for yocto because they have a kind of half-assed version last I checked. But committing to do that for every distro ever? That's not how projects work. The distro packages the project, not the other way around. >> Which busybox commands do you miss that aren't in toybox? I should add them >> to >> the roadmap. (Keep in mind there's a nonzero chance I wrote them to begin >> with. >> Although less so these days because I went through most of that already...) > > I haven't looked into this lately, there are a few we use, ?is your roadmap up > to date, I shall do a comparison check with what we use, and reply about this > then. I update https://landley.net/toybox/status.html each release. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
