On Fri, Sep 2, 2022 at 5:55 AM Rob Landley <r...@landley.net> wrote: > On 9/1/22 15:49, enh wrote: > > The downside of doing that is it would require TOYBOX sed. > > > > meh, _i_ don't care about that :-) > > > > (and, more seriously, does _anyone_ care about using a mixture of toybox > and > > non-toybox? > > At the command level, sure. On macos and bsd you're still using the host > "ps" > because those environments have a very different API from Linux for > getting that > information. Commit 61ef1dccec4e removing getprop/setprop from > toys/android was > an example of cleaning up AFTER "you could use the toybox or non-toybox > version > of things" letting you easily change that decision after the fact. > > Commands calling other commands is sort of a meta-level of this. It's not a > common use case, but the ability to mix and match is sort of a design > hygiene > thing. When mount calls losetup or swapon, I don't want to _require_ that > be the > toybox one because you might need "swapon -L LABEL" which I haven't > implemented > yet, so on your system you've installed another implementation, and if > that's > the only one in the $PATH it should still work. > > Toybox is an implementation of a set of commands. They're bundled together > into > a single executable because doing that makes a significantly smaller binary > footprint (both in storage and at runtime) and has some other advantages, > but it > was never intended to REQUIRE you to use choose all toybox or all > not-toybox. If > somebody needs a feature only available in gnu/tar they should be able to > install that alongside toybox but have it call our gunzip, and people > install > Julian Seward's bzip2 package because they need the compression side or the > shared library so toybox tar should be able to use that bzcat rather than > requiring both implementations to be installed. I don't want anybody to > feel > they're locked in to toybox because of bundling, I want it to be the best > fit > for their needs. > > That said, this one isn't a big objection. Saying "I can't think of a > better > design than adding a bespoke talk-to-tar I/O protocol to sed" is similar > to me > saying "I broke down and rewrote diff from scratch". Minor grumble, I'm not > proud of it, I would rather have come up with something more clever, but > that's > not going to stop me from doing it. This is the best way I've come up with > to > accomplish my goals. Bit disappointed in myself I couldn't do better, but > eh. > Happens. > > That said, I want it to fall back to provide as much functionality as it > does > now when sed --talk-to-tar errors out because it's not our sed. :) > > > i'd imagine the only people who'd even notice would be people like > > me [or these kernel guys] trying to switch over, and the only reason > i/they are > > switching over one tool at a time is because we've been running slightly > ahead > > of you, using stuff that's not finished yet. > > It should still be policy after the 1.0 release. I can't always achieve > interoperability or compatibility, but I would like to where possible. > > > i guess it would affect the toybox > > _tests_ but i kind of thing that's a bug already --- given that i support > > systems where everything's from toybox it's a misfeature that the toybox > tests > > _don't_ test toybox-with-toybox [and i get no value from them testing > > toybox-with-gnu].) > > That's to make sure the tests are real. "It produces the output I told it > to > produce" is a tautology.
aye, but that's the point of having the TEST_HOST variant, so we can test wholly alien implementations as a reference point. the "some toybox, some host" combination -- while not entirely _un_interesting -- is much more niche combo. but at least it's not a new test combination that's making things worse --- it's just a special case of the existing `make test_foo` scenario where we're mostly _not_ testing toybox. we don't have too many issues today that we first find when we run on Android (where ~everything's toybox), and if that ever changes, we can worry about it then. > The code I wrote passing the tests I wrote does not by > itself give me confidence I've actually _proven_ anything. The "IETF > bakeoff" > approach of two different implementations interoperating is a much stronger > statement: not always achievable, but nice when it is. > > Also, as annoying as it is when host upgrades break the tests... that's > kind of > a thing I need to know, and I've tweaked toybox to match what the host is > doing > now on multiple occasions. > > Rob >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
