net-misc/mDNSResponder and net-dns/avahi conflict with eachother. vinagre used to have a use flag to disable the dependency on avahi, but that use flag seems to be removed in 2.14.1. mDNSResponder is required by kdelibs-3.5.10-r2. Masking vinagre-2.14.1 (and staying with 0.5.1) seems to be the only way to update my system. Reproducible: Always
First off, I'm guessing you meant 2.24.1 not 2.14.1. I don't think this can be resolved. The NEWS files for 2.23.1 read: Vinagre 2.23.1 ============== Features + Mandatory dependency on avahi >= 0.6.22 So I don't believe it's optional anymore. I'll pass it to the gnome guys anyway to see if they can come up with an inventive workaround...
Alternatively persuade kde to allow avahi to be installed. I notice that there still a blockage if USE=avahi is set for kde-base/kdelibs.
We are not changing this, it is clear in upstream changelogs and in our ebuild too. If you can kick upstream to make it optional again, we sure will make it optional too for now, we don't have time to fix this.
*** Bug 243044 has been marked as a duplicate of this bug. ***
Created attachment 169666 [details, diff] Make avahi optional This patch adds a --enable-avahi configure switch and does conditional compilation - I hope, I did not miss out on anything.
Created attachment 169668 [details, diff] Ebuild with optional avahi use flag Ebuild which introduces avahi useflag and utilizes the prior posted patch.
I don't know why some gnome developer decided it was a good idea to force avahi on everybody, but for now I created a patch. If upstream really thinks avahi should be mandatory, I would recommend removing vinagre from the gnome metapackage. Linux is about choices, and a remote desktop viewer works damn well without a local mdns search service. What would I need avahi for? Finding VNC-Servers I didn't know about? So I can try to exploit the machine?
Works for me. Thank you, Sven. emerge --depclean felt like I was flushing the toilet. I have dns on my network for a reason, and I don't *want* avahi.
(In reply to comment #7) > I don't know why some gnome developer decided it was a good idea to force avahi > on everybody, but for now I created a patch. Please send this patch to upstream. > If upstream really thinks avahi should be mandatory, I would recommend removing > vinagre from the gnome metapackage. Nope, the point of the gnome meta package is to bring you Gnome as upstream intends it, we thus follow the official Gnome package list. That's the choice we made when making our ebuilds. Feel free to disagree with us however, nothing is preventing you from using your own package set or meta ebuild. We even provide gnome-light for that purpose. > Linux is about choices Please don't go there, bugzilla is not a soapbox. Thanks for your patch, but the proper course of action is to tell upstream how you feel about avahi, because we won't carry this patch without upstream approving it first. Thanks for understanding
replace the AC_DEFINE(AVAHI, ...) by HAVE_AVAHI or WANT_AVAHI (that's just a stylistic or conventional if you will). Other than that the patch looks good, hope upstream integrates it.
(In reply to comment #9) > > Linux is about choices > > Please don't go there, bugzilla is not a soapbox. > > Thanks for your patch, but the proper course of action is to tell upstream how > you feel about avahi, because we won't carry this patch without upstream > approving it first. > > Thanks for understanding > I apologize, I got a little dragged away there, it's just that the only reason I did the patch was because I was so annoyed about something (or body for that matter) forcing avahi on me. Anyhow, since I don't know how to take this upstream it's not gonna happen anyway ... I will keep creating patchs though, I guess.
I submitted a bug and got a response from the author of vinagre, John Wendell. -----My Bug (http://bugzilla.gnome.org/show_bug.cgi?id=557740) ----------- Vinagre's functionality does not depend on avahi. Avahi should be optional. There should be a compile-time option to toggle the avahi dependency. -----His response -------------------------------------------------------- Hi. Avahi is an external dependency of GNOME, as you can see at http://live.gnome.org/TwoPointTwentythree/ExternalDependencies. So, every GNOME application can depend on it. -------------------------------------------------------------------------- So the answer is, "Avahi is an official dependency of "Gnome". It's on the blessed list of "Twenty Three External Dependencies".
Okay, so, avahi is an acepted dependency by the gnome folks. What I am wondering, if I may kindly ask: Since gnome heavily depends on corba (or dbus for that matter), why does vinagre not make use of awarness features instead. Ask if mdns services are available and use them afterwards, through a defined interface like dbus, which would make vinagre work with any mdns service provider (which includes the case of no service provider at all). In a single statement: Why avahi dependencies, when there is a dbus dependency and dbus does manage services? This would put vinagre into a position to determinde the featureset at runtime and no ned to link against a specific mdns package.
(In reply to comment #13) That makes sense to me. FYI: Gilles has kindly rephrased my somewhat terse Gnome bug report. It may also be worth nothing that the following Gnome components appear to still treat Avahi as optional: epiphany-2.24 seahorse-2.22 gvfs-1.0.2 gnome-vfs-2.24 vino-2.24
*** Bug 243006 has been marked as a duplicate of this bug. ***
Here's the latest from the Gnome bug -- per developer Mart Raudsepp, they are considering making Avahi optional: ---- from same Gnome bug referenced above ------------------------------------ Reopening for consideration then. In Gentoo Linux the user could choose if he/she wants avahi support globally or for a specific package, and the distribution doesn't make the choice for him/her but lets them do it themselves, so there is additional value to this, while binary distributions probably would always enable it (which should be the default if the relevant configure option isn't passed) ------------------------------------------------------------------------------
Okay, the patch as I did it does enable avahi by default, if I did not screw something up ;-). Question is, should I beautify the patch as in using WANT_AVAHI instead of just AVAHI?
(In reply to comment #17) Sven, FYI I had submitted your patch in the Gnome bug tracker when I originated that bug. If you enhance it, submit it there too.
(In reply to comment #16) > Here's the latest from the Gnome bug -- per developer Mart Raudsepp, they are > considering making Avahi optional: Err, sorry, that's just me, not "them". I reopened it so that the vinagre developer would reconsider it and then act on the decision, instead of not seeing the bug in open bugs lists at all.
Oops. And I got all excited. Sorry.
(In reply to comment #17) > Okay, the patch as I did it does enable avahi by default, if I did not screw > something up ;-). Question is, should I beautify the patch as in using > WANT_AVAHI instead of just AVAHI? I believe the traditional way is to use HAVE_* if it's something automagically detected, which should be reserved for things like checking for headers to overcome platform differences, and ENABLE_* for things that are configurable with --enable/--disable configure flags. I think the most icky part of the patch is the new glade file, probably duplicating the original. It would be better if it were still the same glade file, but the selection on if the avahi controls are shown or not decided somehow different in code or the glade file - perhaps somehow not showing the relevant container(s) if it's disabled.
Th eproblem is, that libglade reads the glade file and auto-creates all widgets in there, so, the only way is patching the glade file during conifgure, have alternate glade files, remove the widget again after creation, OR remove the widget alltogether and then manually add it if avahi is enabled. Now removing the widget or creating it manually if avahi is present, needs the most code rework, unfortunately I am not into gtk+ or GUI coding, I gotta pass that to someone else.
My workaround for the circular blocking between avahi & mdnsresponder was: emerge -C gnome
FYI, status in bugzilla.gnome.org is "Resolved/Fixed" (as of 11 November): (per Jonh Wendell, vinagre developer) ------------------------------------------------------------------ "OK, guys, you won! Just committed your patch [a bit modified]. This will be in for 2.25 (trunk) though." ------------------------------------------------------------------
My solution was nuntil today to mask >=net-misc/vinagre-2.24.1. But now vinagre-2.24.2 is required by gnome-base/gnome-2.24.1 wicht is required by world. So 'emerge -pvuD world' is bloecked. If I don't mask >=net-misc/vinagre-2.24.1 I get the old: [blocks B ] net-misc/mDNSResponder ("net-misc/mDNSResponder" is blocking net-dns/avahi-0.6.23) [blocks B ] net-dns/avahi ("net-dns/avahi" is blocking net-misc/mDNSResponder-107.6-r5) Any hint apprecieated.
This is offtopic. gnome-base/gnome is not required by world: it is *NOT* a system package. It is a dep, because you may have the gnome flag. To prevent gnome update, you want sth like echo >=gnome-base/gnome-2.24.1 >> /etc/portage/package.mask or track the reasons of the dep (likely USE flags). You may need to mask more ebuilds.
gnome-base/gnome *is* a package like any other. What I would suggest for this particular case *only* is to put vinagre in package.provided. Nothing deps on it within Gnome. Now my 2¢, it would be wise to file bugs for the packages that hard dep on mDNSResponder to be compatible with avahi's mDNSResponder. Has anyone done this? Thanks
As reply on #25: the ebuild and patch work fine for 2.24.2 as well. I've put them in my local overlay. For #26: the dependencies originate from gnome and kde. Perhaps +avahi resolves it, or maybe +bindist, but what if both are not desired?
*** Bug 255827 has been marked as a duplicate of this bug. ***
Pulled the patch from upstream and added to 2.24.2-r1. Thank you for your efforts, Sven and BoneKracker!
That's excellent. Thanks.
