Hi everybody. This is a long note, and it's about the avahi package. It's about changes made in Changeset 27479 (June 7, 2011). Sorry not to have commented earlier, but I was busy on a separate project.
To come directly to the point, and with respect, I think that Changeset 27479 is flawed and needs to be undone. I think it is based on a number of misunderstandings -- see (II) below -- and actually introduces problems which I try to explain below in (I). There actually was a problem with the avahi package prior to Changeset 27479 but I think it's due to the nature of the build process and in any case there is a simple standard workaround. If there's a full fix for it, I'd love to know it. I give my understanding of it below -- see (III). Maybe it is me that misunderstands the situation. However, if you agree with me, I'd be happy to change the avahi Makefile back to what it was before Changeset 27479 (but including a change introduced in Changeset 27521, to disable DBUS support on brcm-2.4, unrelated to the issues discussed here). FYI I'm compiling 10.03.1-RC6 for a Linksys NSLU2. Best wishes Mike Brady (I) Problems with Changeset 27479 1. Changeset 27479 introduces two versions of the package avahi-autoipd; one with DBUS support, and one without. The thing is, avahi-autoipd does not depend on DBUS, so having a DBUS- and non-DBUS version of it makes no sense. What's more, selecting: Network > IP Addresses and Names > avahi-autoipd-dbus <*> (a) does not generate avahi-autoipd, and (b) causes DBUS to be generated and included in the build, even though, as mentioned, avahi-autoipd doesn't need DBUS at all. Also, oddly, the build log shows the avahi package being compiled and installed three separate times, instead of just once. 2. It is possible to select the DBUS- and the non-DBUS versions of some avahi packages at the same time. Of course, this makes no sense, but at least it's pretty obvious when you do it. However, similar problems can occur in a way that's hidden from you. For example, if you select the non-DBUS version of the avahi-daemon package, then the non-DBUS of libavahi will be selected. If you also select avahi-utils, this needs the DBUS version of libavahi. Thus you will be implicitly asking for two different versions of libavahi to be included -- the non-DBUS version and the DBUS version. It's not clear which one will be included in the final build. As mentioned above, the avahi package will be compiled and installed a few times -- five times in this case -- instead of just once. (II) The Possible Misunderstanding in Changeset 27479 It appears that the new Makefile was introduced in Changeset 27479 on the basis of a misunderstanding. In the note accompanying Changeset 27479 it says: "The package was producing a package avahi which required dbus if libavahi-dbus-support was selected (even as module), and without dbus if that package was not select. This has been fixed..." Actually, no "fix" is needed -- this is exactly what is meant to happen: The package libavahi-dbus-support was there to be automatically included if you chose avahi-utils, since avahi-utils requires the DBUS version of libavahi. The selection or omission of libavahi-dbus-support then automatically caused the appropriate version (DBUS- or non-DBUS) of avahi-daemon and avahi-dnsconfig to be compiled, if you had selected them, to correspond with the selected version of libavahi. In summary, starting with a clean system, you got non-DBUS versions of the relevant avahi packages by default, but if you chose something than needed DBUS support (i.e. avahi-utils), or if you selected libavahi-dbus-support manually, you got DBUS versions of all relevant avahi packages. The Changeset 27479 note then goes on to explain that with the new Makefile: "... dbus versions of the binary packages and non-dbus versions of the ones that can be without dbus, so that the smaller platformas can still have avahi without dbus, and those who want the dbus avahi can have it as well." However, this was already the case: as noted above, if avahi-utils was not selected, you were free to choose the DBUS- or non-DBUS version of the other avahi packages by manually selecting or omitting the libavahi-dbus-support. (III) The problem with the avahi package prior to Changeset 27479. There actually is a problem with the avahi package prior to Changeset 27479. Here is a scenario: 1. Choose a set of avahi packages that include DBUS support, and then do a complete build, you'll get the correct versions of the avahi packages and libavahi. 2. Change your choice of avahi packages to omit DBUS support, including only packages that don't need DBUS support, de-selecting avahi-dbus-support if necessary. If you rebuild the system, you may still get the DBUS versions of some of the avahi packages and/or libavahi (this may be the issue that Changeset 27479 was intended to fix). As best I can understand it, the issue is that all releveant packages are not necessarily recompiled, because the "make" dependencies don't seem to allow the build system to force recompilation of the relevant packages. The workaround is to always do a "make clean" before a make when you have changed selections in packages that have previously been compiled. I always understood this was general advice when building OpenWrt, but I'm open to correction. And if there is a way of dealing with this issue, I'd love to hear it. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
