If a package's only dependency is libc

For Developers
1

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

make package/ncurses/compile
make package/ncurses/install

for "libc"?

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?

2

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?

3

Two likely reasons...versioning and testing.

Example -

19.07.8 uses libc - 1.1.24-2

21.02.1 uses libc - 1.1.24-3

The libc version change in 21.02.1 would not have been tested for 19.07.8

However, libc in 21.02.2 uses the same version as 21.02.1

1 Like
4

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.

2 Likes
5

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.

2 Likes
6

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?

7

Also, are luci-app-x packages likely backward compatible, from 21.02.x to 19.07.x? There're quite a few that're only officially available on the latter.

8

Well, it is upto you to find out if the LuCI apps work ok. In general, they may be compatible, but something may have changed either in the underlying OpenWrt, underlying package or in LuCI infra.

Same goes for the start priority debugging. Hard to say anything without even knowing which packages you are talking about.

9

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.

10

The start priorities are not synchoronous, so possibly it started before some other earlier started services (and addresses, interfaces, etc.) were up.

1 Like
11

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.