Hi Jon. Thanks for the pointers. Yeah, I was a tiny bit surprised to hear nothing. I didn't know how to contact the committers, TBH. Are you a maintainer yourself?
Mike On 8 Nov 2011, at 17:43, Jonathan McCrohan wrote: > 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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
