Right now, many targets build multiple image types, e.g., "factory", "factory-EU", and "sysupgrade". Likewise, the x86/64 target builds six image types, three with ext4 (combined-efi + combined + rootfs) and three with squashfs.
I hereby argue that:
the purpose of having separate ext4 and squashfs images is not the same as the purpose of having separate factory and sysupgrade images;
the end result of "flashing" ext4 and squashfs images is not equivalent in terms of available functionality (e.g., factory reset or getting the modified configs only), while it is equivalent for factory and sysupgrade;
the mere existence of the ext4 image types breaks the image build for certain package combinations that would be viable for squashfs due to compression, while this should never be the case for the factory/sysupgrade pair.
As an example of the last point, try using the online image builder and include dockerd and docker. The build fails because the result does not fit into 128 MB when using ext4.
If one uses the offline image builder and edits .config to disable the build of ext4 images, the squashfs image builds successfully, with a lot of space available.
Therefore, a proposal: split the x86/86 target into two, one with ext4 images and one with squashfs images. Then the users of ext4 will get what they got before, and I (a squashfs user) will be able to build factory-resettable images containing Docker using the online imagebuilder.
The root size is orthogonal to my proposal, as somebody else will then still say "packages A + B + C + D fit in squashfs but not in ext4, and the buildsystem still blocks squashfs creation because of that ext4 space limit".
Is there any other case where the same target builds two images with radically different amounts of usable space?
I know you meant it rethorical counter question but yes, all xxxxxxpi booting from sdcards count.
ext4 makes no difference you stuff the docker in imagebuilder or much later after resizing root.
That's useful info, thanks. In the RPi4 case, it's the same "ext4 vs squashfs" situation, so this proposal becomes a broader policy question, not limited to x86/64.
You are right about the "unlimited" storage. Yet, the ability to run unattended sysupgrade (or sysupgrade in general without any post-upgrade steps) also matters, and this is what would "preinstall" everything that I added after the initial "flashing".
My way of using OpenWrt on x86/64 was to add an extra partition that the usual sysupgrade process preserves, mount it, and put data (including Docker containers if needed) there. The original 128M partition would then be completely overwritten with every sysupgrade.
I'm a nobody here, but it seems to me that the failure of a given image type to build should never prevent the building of any other image type that may succeed.
This clearly needs to be fixed, whatever the specific solution.
Targets/ subtargets are costly in terms of buildbot requirements and (mirror) storage, as well as on the developer side (e.g. upgrading the kernel, you're multiplying the efforts required with each new (sub-)target, that is very painful on the human resources), inflating them is not a good idea (on the contrary, I don't see any reason for three 32 bit x86 targets anymore/ ever). I haven't really seen (non-)technical reasons for doing so either.
yes, but that isn't really a reason for a (sub-)target split either - and you can cross-grade between ext4 and squashfs
correct, but not a reason to split
if either of them fails to build, the other shouldn't be affected already (missing image builds are silently ignored, because that happens all the time for 4-/ 8 MB flash non-x86 routers). That said, build failures (of any kind) just need to be fixed, the same as any other bug - and it's pretty unlikely that OpenWrt's default image builds will exceed their 104 MB limit anytime soon either (and if they do, it's simply a case to bump the value - which imho should be done anyways)
There is a lot of optimization potential for OpenWrt on x86_64, but I don't see a need or a compelling argument for an artificial target split.
--
Disclaimer: I'm not an OpenWrt developer and can't speak for the project, the opinions stated above are my own -only- and not coordinated with anyone.