Sime makelike wrapper scripts support

Eli Schwartz eschwartz at archlinux.org
Wed Jan 15 16:49:42 UTC 2020


On 1/14/20 4:29 PM, Laurent Bercot wrote:
> 
>> This is not a general condemnation on implementing a busybox binary that
>> you've just arbitrarily decided "shall not be accepted" simply by fiat,
>> without provided rationale and without being the project maintainer who
>> actually has the right to arbitrarily decide things.
> 
> But I did provide a rationale: it's creeping featuritis, plain and
> simple. If you found my posts offensive, be assured that it's nothing
> compared to how offensive the idea is to me that "mim" and "make"
> should be part of busybox.

I didn't find it particularly offensive, I just thought your second post
was a lot less original than your first post.

(Well, I did make a comment about "sheer principled outrage". But I
don't consider sheer principled outrage to be fundamentally offensive,
merely inconsistent with the presence of diff/patch.)

As for mim, it offends my principles too... I thought maybe discussing
the inclusion of a tool that's actually useful to more than one person,
like an actually standards-conformant "make", would be a more
interesting direction to pursue, should anyone wish to make busybox more
friendly to being used in alpine docker containers without additional
packages. I'm quite positive that it would be more productive to the OP,
given that "mim" has approximately 0% chance of inclusion.

> No, I'm not the maintainer, thank God. (If I was, I would be forced to
> be polite and oppose reasonable arguments to unreasonable proposals,
> and doing this with my own projects without ever losing my temper is
> enough of a pain in the ass as is.)
> 
> But I've been a busybox user for long enough, and in enough varied
> environments, that I happen to have a rather good idea of what would
> probably be a good fit for busybox and what would not. Sometimes it's
> not clear-cut, sometimes there are arguments for and against, and it
> becomes a matter of opinion, and ultimately the maintainer's opinion
> prevails.
> 
> "mim" and "make" are not even close. For very different reasons, left
> as an exercise to the reader for now because I'd like to have dinner
> soon.
> 
> So, yeah, that's just my not-humble-at-all opinion, and I'm a peasant,
> but a peasant who likes his tools and would love to keep them free of
> useless add-ons. And, unfortunately, who's not always successful at
> preventing them.
> 
> 
>> And after all, why include patch and diff applets, then reject make on
>> sheer principled outrage?
> 
>  Now *that* is a good question, and a discussion worth having. My answer
> to it is twofold:
> 
>  - If it had been my decision, patch and diff wouldn't have made it
> into busybox. That's as simple as that. I've had disagreements with
> Denys before, and my position is that busybox *already* has too much
> stuff in it. Other users like it the way it is, because to them busybox
> is a one-stop shop; but my opinion is that offloading integration work
> to busybox is doing a disservice to the project.

Okay, and with that, your objection to including a make applet makes a
lot more sense. ;)

I don't even necessarily disagree with you. I think that's a reasonable
perspective to have, and I'm not strongly inclined either way.

>  - The very fact that you are using the existence of the patch and diff
> applets as an argument in favor of the inclusion of make is *exactly*
> why creeping featuritis is so insidious and terrible. You're right,
> since we have patch and diff, why not add make? And, since we started
> so well on the path of development tools, why not add binutils, and a
> C compiler, and autotools, and git? Slippery slope is very, very
> slippery.
> 
>  We have a duty to recognize creeping featuritis for what it is when it
> happens, and I'm saying - loudly and unpleasantly because I don't like
> to be the one having to spend time on this - that this thread is pure
> unadulterated unchecked creeping featuritis, and every time a similar
> proposal is not met with a hard NO, the value of the busybox project
> decreases.
> 
>  Now, am I talking to software engineers, or do I really have to explain
> *why* the value of the project decreases with every useless additional
> applet, *even when* there is a configuration switch that can disable it
> at build time?


-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20200115/bf3c56c8/attachment.asc>


More information about the busybox mailing list