[Aboriginal] dev-environment.sh depends on gnu coreutils

John Spencer maillist-aboriginal at barfooze.de
Tue Mar 11 01:29:01 PDT 2014


Rob Landley wrote:
> On 03/02/14 13:57, John Spencer wrote:
>> Rob Landley wrote:
>>> On 02/28/14 09:02, John Spencer wrote:
>>>> on my busybox install (sabotage linux):
>>>>
>>>> ~/qemu/system-image-sh4 $ HDBMEGS=2048 ./dev-environment.sh
>>>> ./dev-environment.sh: line 44: truncate: command not found
>>> It's been in toybox since 2011:
>> so what ? it's by no measure a *standard* command at all.
> 
> Please point me to the posix entries for chroot, eject, ifconfig,
> insmod, losetup, netcat, swapon, which, whoami, yes, install, killall,
> reboot... heck even _tar_ isn't posix (they went with "pax" and an ever
> so slightly different archive format).

doesnt change the fact that tar is available everywhere, same as dd.

> 
> The initramfs developers still get flames about having gone with cpio
> instead of tar for the archive format. (Given that the guy who made the
> call was Al Viro, he ignores them.)
> 
>> just that you implemented it for toybox doesnt make it any more portable.
> 
> Here's a freebsd man page for truncate from 2006:
> 
> http://www.freebsd.org/cgi/man.cgi?query=truncate
> 
> Here's the command added to coreutils in 2008:
> 
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=75e0047c4b916393b6be3cb985c4c4d4a2d1a836
> 
> Here's a man page from Ubuntu 10.04:
> 
> http://manpages.ubuntu.com/manpages/lucid/en/man1/truncate.1.html
> 
> (I think you could upgrade 8.04 and get it with the new version of
> coreutils, but since that hit its 5 year "long term support" end of life
> a year ago the upgrade servers have gone down.)
> 
> Widespread deployment of this command predates qemu's 1.0 release.

it's not about that some platforms have it, it's about that some 
platforms have it *not*.

> 
>> this is the first script i've encountered in my whole life that uses
>> this exotic command.
> 
> I didn't make aboriginal use it until it had been in coreutils for 5
> years. I have no control over your awareness of a given command's
> existence, but it wasn't exactly a secret:
> 
> http://landley.net/notes-2011.html#08-06-2011
> 
>>> http://landley.net/hg/toybox/rev/396
>>>
>>> I've been losing track of what busybox does or doesn't have, I pretty
>>> much only use the busybox-baseconfig non-toybox subset these days.
>>>
>>>> i suspect there's a portable command that could be used instead, for
>>>> example
>>>> dd if=/dev/zero of="$imagefile" bs=1 count=0 seek="$imagesize"
>>>> creates a spare file of the required size in 0.0 seconds.
>>> It used to be using that:
>>>
>>> http://landley.net/hg/aboriginal/rev/1630
>> reasoning for replacing a standard command with a non-standard one:
>> "It's been long enough since "truncate" was introduced"
> 
> No, the reasoning is that dd can never create a fully sparse file, and
> the truncate syntax for doing so is simple and straightfoward where the
> dd syntax is anything but.

oh ? do you have more detail on that ?
i guess it would have been helpful to have this reasoning/information in 
the commit message then.

> 
> Also that it had been in coreutils for 5 years and in BSD before that.
> 
>> huh ? you're meaning introduced to toybox ? so do you want to force
>> anyone that wants to use aboriginal to install toybox just to be able to
>> use some shell scripts ? come on, this is silly.
> 
> No, if that was the case I would have made Aboriginal use the "touch -l"
> extension added to do this back in 2007:
> 
> http://landley.net/hg/toybox/rev/162
> 
> (Which was ripped out in favor of implementing the much more standard
> truncate command.)


following your logic, it's reasonable for the kernel developers to use a 
bit of perl here, a bit of bc there, and some python over here.
because they all have been on ubuntu since 5 years.

> 
>> my interest to compile alpha toybox is *zero*, and i dont plan to
>> replace busybox with it until it's seen at least a decade of thorough
>> testing in embedded products all over the world.
>> so at the current development speed this is 20 years in the future.
> 
> So you won't start using toybox for a decade after its 1.0 release. The
> qemu 1.0 release was December 1, 2011. So presumably you'll start using
> qemu in 8 years?
> 
> No, that doesn't make sense. we're talking about the qemu wrapper
> script, all it does is launch qemu. You must mean from the START of the
> project. (In which case you've only got 2 more years to wait until it's
> a decade for toybox.)

no, it doesnt just launch qemu, it also prepares your work environment - 
and that part is broken for busybox users.

> 
> Let's see, the first commit in the qemu repository was February 18,
> 2003, so congratulations on your one year anniversary of using qemu! I'm
> sorry that my qemu wrapper script was only of use to you for part of
> that time. (We _are_ still discussing the contents of the qemu launcher
> script, right?)

you're mixing apples and oranges. qemu is not comparable to 
toybox/busybox: the former is a single application, the latter are 
collections of almost any standard utility. and i rather have these well 
tested.

> 
> Leaving aside your complete dismissal of my current main project as a
> negotiating tactic... ("That new thing you're spending all your time on?
> I will _never_ care about it. Now do what I told you to do on this other
> thing you're only really still putting any time into as a test harness
> for that new thing.")

i have no influence on what projects you hack on.
i like and use your aboriginal project, but toybox is currently a 
building lot, incomplete, and lacking sufficient testing.

so i see no reason apart from GPL hate (which i dont feel) to leave 
busybox (which is almost feature-complete, well-tested, and has almost 
all commands i need) behind and switch to a software in pre alpha shape.

this includes playing pre-alpha-tester for toybox via aboriginal.
imo you shouldnt mix these two projects together.

> 
> You _are_ aware that projects like busybox can build individual
> commands, right? So you can just add the _one_ command without affecting
> the rest? (Even if you don't want to use scripts/single.sh you can just
> make allnoconfig, switch on truncate, make toybox, mv toybox truncate,
> just like you would with busybox?)

the point here is that adding yet another command will just make my 
busybox binary bigger, and result in one more symlink in my already 
fullstuffed /bin. and having to add a new command just to make a single 
app that uses it happy kinda sucks.

> 
>> it's bad enough that you still stick with GNU bash scripts despite your
>> GNU hate.
> 
> I intend to implement a reasonable bash replacement shell in toybox.
> 
> That said, a todo item near the top of my aboriginal todo list is seeing
> how much of my scripts will run with busybox ash. (Last time I tried:
> not much.)
> 
> Alas, given that I'm mostly using aboriginal as a toybox test bed these
> days and it gets about the fourth slice of my hobby programming time...
> (There's a ton of stuff i want to do. And with my current dayjob, 3-4
> hours of commuting time to and from work each day.)

i think others use aboriginal for other purposes, which do not involve 
testing toybox. and in my case, i would prefer if busybox was installed 
instead of toybox, so stuff (including date) would just work.

anyway, it was not my intention to turn this into a toybox rant.

> 
>>> Feel free to locally revert that patch, but the proper fix is either for
>>> busybox to implement truncate or for me to finish toybox. :)
>> no, the proper fix is to use a portable command, i.e. revert the patch
>> "globally" in aboriginal.
> 
> Because me pointing out the patch you can revert locally is _unclean_,
> and you're fighting on behalf of all those other silent people who can't
> be bothered.

yeah, i joined your fight to get the perl dependencies out of the kernel 
build process, and now i fight to get the coreutils/toybox dependencies 
out of the aboriginal usage process.

> 
> You won't use coreutils either, presumably until 4 more years have
> passed and the truncate command has been around for your 10 year metric.
> 
> You could always install that freebsd one, you only have to wait 2 more
> years for that one to be "ripe".
> 
> I assume asking the busybox developers to add a truncate command would
> still saddle you with a ten year waiting period...
> 
> You could write your own truncate, since it's a trivial wrapper around a
> single syscall. The toybox one is 26 lines, half of which is the
> menuconfig entry. Almost all of the actual work is command line option
> parsing.

again, i just don't want to add yet another command just to make a 
single program happy. it doesnt matter how much code that program is, it 
matters that it sits in my /bin unused for 99.99999999999% of the time, 
so it just shouldnt be there to begin with.

> 
> But then you'd have to wait 10 years.

hm ?

> 
> Rob
> 


 1394526541.0


More information about the Aboriginal mailing list