...I need a container and I decided to base it on TC so a generic/small linux-toybox-roofs should not fit the bill. The advantage of using TC is the TCE, there is a lot of application just ready to be used.
A developing environment running in qemu is not a new. To have one based on TC, I need to build a customised ISO/image. Finally, I can use the customised image to create a chroot jail in such a way I do not waste time in qemu boot time and slowliness. So, the ISO/image would be interesting for real-hardware and qemu-test but the chroot jail will speed up the developing process.
Let me simplify for you the basics:
A. You "work" with containers -> no comments..
B: You "work" with CHROOT: so you limit yourself to the
same CPU arhitecure: you can not chroot from a x86_x64 (or x86) into an arm7 CPU arhitecure. Hmm, lets not talk about
security in chroot. Neither about
proper isolation (libs leakage) between host and guest (chroot).
C: You "work" with QEMU:
did you try what I "recommended", the previous link? So are you "developing" appls? This means you have a lot of RAM and CPU power (to compile) and huge HDD space to store the intermediar/test result etc.
And you are worry that a qmenu will boot that minimal linux kernel (2-4 MB) in 2-3 seconds; but your work, compile, test, etc is for many hours /day? Nice joke!
And you are worry that qmenu is slow? Because you did not try the qemu KWM-module accelerator to have
same native speed (98-99%) in guest VM as in the host? nice joke again!
Did you measured it before you speak? You want to build an ISO/cdrom image -> so you still need boot a kernel. But qemu can boot FASTER than an ISO, because "qemu kernel=.. initrd=..". Lets not talk about you wasting aditional time with "mkisofs ISO" versus 3 seconds qemu boot.
I think you did not undestand me. Let me explain it again more cleary.
You manage to be in a "buiding environment" (by using a container, or chroot, or qemu, whatever). And you are now in a
shell (toybox, busybox, whatever) with a
rootfs (/bin, /sbin, /usr..) on whatever medium (locally, or mouned qemu sda, or loop mounted).
From this moment, you are free to "borrow"
any new shell and utils: a busybox you want (if toybox in not enough for you). Even copy / paste a busybox from tc (libc, dynamic) or from AlpineLinux (musl, static linked) etc.
Further from here, you download and mount the tcz you need (compile.tcz, gcc.tcz -> compiler).
The "TCE" means: kernel + modules + busybox (shell) + few GUI-FLTK_apps (mount, editor, cpanel etc). What do you talk about in TCE basic? Do you need the FLTK apps? And you can not simple copy/paste them in your new "buiding environment"? You need another kernel verison? Or another shell+rootFS, and you did not find any already made for you?The
external tcz appls are just squshFS archives, which you mount into whatever rootFS you choose.
Summary: you could build any-kind of TC, using any kernel version you want, and any shell you want. But if you want lazy (already made) tczs - which are libc linked -they are free to download already from servers.