Hi Mike, I'm a bit surprised you haven't got any replies yet; Either nobody seems to care, or else nobody else seems to use avahi.
You might be better off emailing cshore [1] directly as he committed r27479. Failing that, you can email thepeople [2] and offer to be the avahi maintainer. Then just fix up the package as you like, and commit your own changes. ;-) Jon [1] Daniel Dickinson <dan...@cshore.neomailbox.net> [2] Travis Kemen <thepeo...@openwrt.org> On 6 November 2011 15:55, Mike Brady <mikebr...@eircom.net> wrote: > 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 > _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
