Due to circular dep chain: gtk+[cups] -> cups[avahi] -> avahi[gtk] -> gtk+ and not converted-yet qt4 ;).
I hope this is not a blocker to stabilization. We've had this circular dep before and had to live with it. I'm stabilizing in bug #520338.
(In reply to Anthony Basile from comment #1) > I hope this is not a blocker to stabilization. We've had this circular dep > before and had to live with it. I'm stabilizing in bug #520338. Sorry for not replying earlier but I didn't reply since it's not ;). We'll updated the deps in a revbump. Assuming the update is necessary since now I'm finding out whether multilib libavahi-ui is actually used somewhere.
So I've did some research and no dependency of multilib avahi is currently linking to libavahi-ui. Do you think we ought to skip that library for multilib?
Oh, I'm talking to myself.
(In reply to Michał Górny from comment #3) > So I've did some research and no dependency of multilib avahi is currently > linking to libavahi-ui. Do you think we ought to skip that library for > multilib? Yes, let's skip it. We can return to this if something requires a multiblie libavhi-ui.
(In reply to Michał Górny from comment #0) > Due to circular dep chain: > > gtk+[cups] -> cups[avahi] -> avahi[gtk] -> gtk+ > > and not converted-yet qt4 ;). One more piont, what needs to be converted here for gtk and qt4???
If we drop libavahi-ui, we don't need all those deps.
(In reply to Michał Górny from comment #7) > If we drop libavahi-ui, we don't need all those deps. Its unclear what you want here. Suppose we keep libavahi-ui, what needs to be converted? Can you give me a patch to explain what you mean by "and not converted-yet qt4 ;)"
Look at dates. If we drop libavahi-ui, we don't need anything more. If we want to keep it, we need gtk3 now (that was added after the bug was opened).
(In reply to Michał Górny from comment #9) > Look at dates. If we drop libavahi-ui, we don't need anything more. If we > want to keep it, we need gtk3 now (that was added after the bug was opened). I'm not following you here. Please provide a patch.
(In reply to Anthony Basile from comment #10) > (In reply to Michał Górny from comment #9) > > Look at dates. If we drop libavahi-ui, we don't need anything more. If we > > want to keep it, we need gtk3 now (that was added after the bug was opened). > > I'm not following you here. Please provide a patch. Sorry now I get what you mean (after IRC chat). For the records let me record it here: we have two options now 1. keep 32-bit libavahi-ui (nothing uses it right now) -> we have to convert gtk:3 and deps to multilib, then just add MULTILIB_USEDEP wherever appropriate in avahi 2. drop 32-bit libavahi-ui -> we need to stop building the library, so some hackery in the ebuild but we lose deps on 32-bit gtk+, gtk+3, qt4 <mgorny> the key point being here is that even though nobody right now needs 32-bit libavahi-ui, building 32-bit avahi pulls in 32-bit gtk+, gtk+, qt4 if they're requested in native my response: I think we should go for 2 because it is inevitable that we will need to convert gtk+ gtk+3 and qt4 to multilib, and because it future proofs avahi in case something in the future needs libavahi-ui.
> my response: > > I think we should go for 2 because it is inevitable that we will need to > convert gtk+ gtk+3 and qt4 to multilib, and because it future proofs avahi > in case something in the future needs libavahi-ui. I mean option 1. Sheesh!
+*avahi-0.6.31-r7 (22 Nov 2014) + + 22 Nov 2014; Michał Górny <mgorny@gentoo.org> +avahi-0.6.31-r7.ebuild: + Enable remaining multilib deps (UI libraries), bug #510182.
