Actually, make it two packages, whose only dependency is "libc". I see "libc" selected (--, dash-asterisk-dash) in menuconfig -> Base System, but there're numerous other packages also selected, such as getrandom (--, dash - asterisk - dash), and logd (<*>, open-angle-bracket - asterisk - closing angle-bracket). Do I need to keep those as they are, or could those others be un-selected?
Also, what's the equivalent of
Also, it isn't clear what https://openwrt.org/docs/guide-developer/toolchain/single.package means by "tick the package you want to build". Does "tick" here mean pressing "Y" to put an asterisk next to the single package I want to build? Or does "tick" mean pressing "M" to put "M" ("modularize feature") next to the package wanted?
Huh, it's actually possible to build packages marked for v21.02 for v19.07.x instead, by just overwriting a particular package's Makefile and optionally package_name.init files (while the package_name.config files are usually identical) for the latter (v19.07.x).
So what's preventing v19.07.x from getting the same latest packages as on v21.02, other than man-hours?
Well, the main question is, what is preventing 21.02 to have the same packages as the latest master?
And the answer to both is your guess, man-hours, plus boringness. Backporting stuff to stable branches is boring. Everybody "at OpenWrt" is a volunteer and usually likes to tinker with new stuff...
Most of the enthusiasts are usually using master, so even the stable 21.02 is already badly behind the master branch, as nobody really runs it. And 19.07 is naturally even more behind. Backporting more complex stuff would usually also require running the software in the old firmware, and people are not that enthusiastic to lose the newer functionality...
Note that 19.07 will possibly be declared "end-of-life" in March or April, once 22.0x has branched.
Besides that, where'd the "stability" of a "stable release" go, if huge amounts of packages (feed or base doesn't really make a difference here) would be backported blindly? Once you go there, why would releases be done at all?
While those are valid maintenance approaches as well, they'd be very much at odds with the current release model.
Uh, out of the two v21.02 packages that I compiled for v19.07.9, one doesn't start via init.d/procd anymore, unlike back on v19.07.8. I could still start it manually by calling the executable binary directly. It doesn't produce any debug output on the CLI, even after I added PROCD_DEBUG=1 and INIT_TRACE=1 to its init.d script and tried to manually kick it off via the init.d script, unlike back on v19.07.8.
At a cusory glance, the init.d script looks the same as the 5-6 year old version currently latest officially available for v19.07.x.
I took a chance and changed START=50 to START=99 in its init.d scrip. Strangely then it's able to start. Thereafter I changed it back to 50, and it's been stopping and starting fine, since. What's wrong with this picture?
The 21.02 package that doesn't start on 19.07.9 as built is "udpxy" v1.0 (build 25). The latest available for 19.07.x is v1.0 (build 23). More strange was the fact the debug params added to the init.d script produced no CLI output, until after the START=## change as well.
I tried restarting /etc/init.d/udpxy a bunch of times, after the device has been up for quite a while (a few hours) though. So everything else that should start should've long been up and running. I don't get why changing the start priority would have an effect so long after the proper startup.