[Toybox] "bad xform" not very helpful

[enh]

On Fri, Sep 2, 2022 at 5:55 AM Rob Landley <rob at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220902/e9035c52/attachment-0001.htm>