Bug 510182 – net-dns/avahi: revisit USE=gtk,qt4 once deps are converted

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Michał Górny 2014-05-12 18:54:24 UTC]

Due to circular dep chain:

  gtk+[cups] -> cups[avahi] -> avahi[gtk] -> gtk+

and not converted-yet qt4 ;).

[Comment 1 Anthony Basile 2014-08-20 17:26:23 UTC]

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.

[Comment 2 Michał Górny 2014-11-20 09:39:57 UTC]

(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.

[Comment 3 Michał Górny 2014-11-20 10:17:44 UTC]

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?

[Comment 4 Michał Górny 2014-11-20 10:18:27 UTC]

Oh, I'm talking to myself.

[Comment 5 Anthony Basile 2014-11-22 12:41:21 UTC]

(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.

[Comment 6 Anthony Basile 2014-11-22 12:49:11 UTC]

(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???

[Comment 7 Michał Górny 2014-11-22 14:01:45 UTC]

If we drop libavahi-ui, we don't need all those deps.

[Comment 8 Anthony Basile 2014-11-22 14:30:07 UTC]

(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 ;)"

[Comment 9 Michał Górny 2014-11-22 15:01:48 UTC]

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).

[Comment 10 Anthony Basile 2014-11-22 15:08:28 UTC]

(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.

[Comment 11 Anthony Basile 2014-11-22 16:42:40 UTC]

(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.

[Comment 12 Anthony Basile 2014-11-22 16:43:25 UTC]

> 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!

[Comment 13 Michał Górny 2014-11-22 23:32:51 UTC]

+*avahi-0.6.31-r7 (22 Nov 2014)
+
+  22 Nov 2014; Michał Górny <[e-mail]> +avahi-0.6.31-r7.ebuild:
+  Enable remaining multilib deps (UI libraries), bug #510182.