Firmware selector can't build in both avahi-utils and avahi-daemon-service-http

Installing and Using OpenWrt
1

When I run imagebuilder myself, I select additional packages in this order, which is necessary to install libavahi-dbus-support instead of libavahi-nodbus-support:
avahi-utils avahi-daemon-service-http

I tried using the firmware selector to build an equivalent image, but even when I specify those two packages in that order, it fails. Example for NETGEAR Nighthawk X4S R7800, SNAPSHOT, with those two packages added to the end of the default list:

 * check_data_file_clashes: Package libavahi-dbus-support wants to install file /builder/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/root-ipq806x/usr/lib/libavahi-common.so.3
	But that file is already provided by package  * libavahi-nodbus-support

Is there something going on in the firmware selector that sorts the list of packages? That would explain why this pair of packages doesn't work, because in sorting order they are in the opposite of the order that works for me on my own image builder.

Is there a way to get firmware selector to attempt to include packages in the same order as I enter them?

2

That's probably opkg checking dependencies and the firmware selector is including something it shouldn't. FS uses the asu server build backend, which in turn just launches off the proper image builder, so ultimately both of your builds are in the same hands at that end stage.

I would first try removing the "already providing" package with -libavahi-nodbus-support on the firmware selector, see if that alone does it. If not, maybe add libavahi-dbus-support explicitly?

3

Tried both libavahi-dbus-support and -libavahi-nodbus-support already, no help. If the firmware selector sorts package names, that is consistent here because avahi-* is before libavahi-* and the override is processed too late.

The "already-providing" package causing me trouble is one of the two I want to install.
I get a succesful build when asking the firmware selector include either avahi-utils, or avahi-daemon-service-http, but it won't do both. avahi-utils requires libavahi-dbus-support; avahi-daemon-service-http can use either libavahi-dbus-support or libavahi-nodbus-support.

imagebuilder builds of my own can do both, but only if the two packages are specified in reverse alphabetical order. imagebuilder fails if the two are specified in alphabetical order.

4

Yup, your deductions are correct, FS does sort the list. (Although I'd say it's a bug in the image builder -- meaning opkg -- if it forces a certain order on package installation.) Maybe put in an issue, see if @mwarning or @aparcar can shed any light?

2 Likes
5

hm, yeah. This is weird. I would expect that the order "should" not matter. But apparently it does. @aparcar do you mind if we remove the sort?

6

I don't think the sort in FS makes any difference. I sent the ASU build api a couple of requests, with both package orders, and both builds failed with that same error. It appears that ASU is sorting them internally after receiving them (although I haven't dug into it yet).

(Also, auc does not sort its package list, but LuCI Attended Sysupgrade appears to do so https://github.com/openwrt/luci/blob/master/applications/luci-app-attendedsysupgrade/htdocs/luci-static/resources/view/attendedsysupgrade/overview.js#L479 )

Edit: Sho 'nuff, ASU build sorts them: https://github.com/openwrt/asu/blob/main/asu/build.py#L158

1 Like
7

OK, then there is no reason to remove the sort in the firmware selector unless ASU removes it as well..

1 Like
8

I concur. As we both agree, "order shouldn't matter" and I think this should be dealt with by the package manager. Hopefully apk handles these cases appropriately and we don't have to mess with (soon-to-be dearly departed) opkg...

Just for completeness, here's the line where the bad behavior resides:

9

Yes, it shouldn't matter, but I think it has to matter. There are sometimes multiple packages providing a given shared library file, one with slimmed down functionality and one with full functionality. libavahi-nodbus-support and libavahi-dbus-support are just one example. There are others like wpad-mini vs. wpad. There are higher level packages that can install atop of either of the supplying packages. The trouble comes when one package requires a specific variant (avahi-utils requires libavahi-dbus-support) and another package can use any variant (avahi-daemon-service-http).

So maybe yes the package manager should be smart enough to do the closure of all the packages and find a solution that satisfies them all. But it's not that smart today. It seems to just take packages in order, recursively finds satisfying dependencies (without any lookahead to determine the "best" dependency for all the packages in the install list), and then chokes when the next package in order requires a different supplier of a file already supplied by a previous package's dependency. For the current implementation of package manager, we have to give it hints by installing packages in a certain order to provide a compatible solution to all the packages requested.