Re: [OpenWrt-Devel] Avahi package problems
Hi. Here is the list:
avahi-autoipd -- doesn't depend on DBUS at all, it's the only DBUS "don't care".
libavahi, avahi-daemon, avahi-dnsconfd -- can be DBUS-enabled or not.
avahi-utils, libavahi-client -- these require DBUS.
If avahi-utils or libavahi-client is selected, then the DBUS-enabled version of
libavahi, avahi-daemon, avahi-dnsconfd must be selected as well.
The avahi makefile prior to Changeset 27479 looked after all the above.
I'd be happy to fix all this up incorporating the effect of Changeset 27521
over the next few days, and submit it as a patch -- just let me know.
Regards
Mike
On 8 Nov 2011, at 21:09, Nico wrote:
> Hi,
>
> On Tue, Nov 8, 2011 at 6:46 PM, Mike Brady wrote:
>> 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?
>
> I will try to fix it. From your experience, can you remind me which
> binaries are needing DBUS enabled and which don't care ?
>
> Thanks for your detailed explanation and your help,
> --
> -{Nico}
> ___
> 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
Re: [OpenWrt-Devel] Avahi package problems
Hi,
On Tue, Nov 8, 2011 at 6:46 PM, Mike Brady wrote:
> 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?
I will try to fix it. From your experience, can you remind me which
binaries are needing DBUS enabled and which don't care ?
Thanks for your detailed explanation and your help,
--
-{Nico}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Avahi package problems
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 > [2] Travis Kemen > > On 6 November 2011 15:55, Mike Brady 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
Re: [OpenWrt-Devel] Avahi package problems
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 [2] Travis Kemen On 6 November 2011 15:55, Mike Brady 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 th
[OpenWrt-Devel] Avahi package problems
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
