From the ebuild : if ! use h323 && ! use sip; then eerror "You have disabled h323 and sip USE flags." eerror "At least one of these USE flags needs to be enabled." eerror "Please, enable h323 and/or sip and re-emerge ${PN}." die "At least sip or h323 need to be enabled." fi if use kontact && ! use kde; then eerror "To enable kontact USE flag, you need kde USE flag to be enabled" eerror "Please, enable kde or disable kontact and re-emerge ${PN}." die "You need to enable kde or disable kontact." fi Please fix this as soon as possible, this is a major ebuild QA problem and I've given numerous suggestions on IRC. Thanks
For sip/h323, I've sent a patch upstream to have SIP always enabled and H.323 optional. At the moment they are auto-magic deps and ekiga can't work if noone is enabled. If upstream accept this patch, I will change the behavior in Gentoo. For kontact/kde, I should think about that. As I said in the other bug about ptlib/opal dying because of USE flags, I understand it's annoying but with EAPI-2 USE flag dep, it's not safe to change the behavior of a USE flag. For ptlib/opal, I will try to fix the most annoying messages, for this one, I will wait until I will get comments from g-dev (I should send an email).
(In reply to comment #1) > For sip/h323, I've sent a patch upstream to have SIP always enabled and H.323 > optional. At the moment they are auto-magic deps and ekiga can't work if noone > is enabled. > If upstream accept this patch, I will change the behavior in Gentoo. Could you consider dropping the "sip" USE flag? That would make dying moot as at least one protocol would always be enabled. _And_ it reduces the number of USE flags. Not every single package option should be visible as a USE flag. Take xorg-server for instance. We could easily triple its number of USE flags, but we keep them to a minimum because it doesn't make sense to have that much control over build options. > For kontact/kde, I should think about that. > As I said in the other bug about ptlib/opal dying because of USE flags, I > understand it's annoying but with EAPI-2 USE flag dep, it's not safe to change > the behavior of a USE flag. You're the maintainer of all the pieces, you get to decide what they mean. And you can check the gentoo tinderboxes to see if other packages need to be modified. Thanks
ekiga-3.2.5-r2 is removing sip USE flag and h323 is no longer auto-enabled. This is fixing the first part of the bug. For the second part, as I said in gentoo-dev ml, I don't think we should silently add --enable-kde if kontact USE flag is enabled even if my solution is not the best but it's at least safe and clear.
(In reply to comment #3) > ekiga-3.2.5-r2 is removing sip USE flag and h323 is no longer auto-enabled. > This is fixing the first part of the bug. Great, thanks! > For the second part, as I said in gentoo-dev ml, I don't think we should > silently add --enable-kde if kontact USE flag is enabled even if my solution is > not the best but it's at least safe and clear. Honestly, I don't mind if you make the ebuild disable all kde/kontact support if USE="-kde kontact" is set by the user. That's still fine by me and your appreciation is what's important. All I request is that the ebuild doesn't die() in pkg_setup because of weird USE flags. As an example, in the pixman ebuild, if a user sets USE="-mmx sse2", I actually _disable_ both MMX and SSE2 support because it doesn't make any sense. In any case, thanks for fixing it up, users will appreciate it :D
(In reply to comment #4) > As an example, in the pixman ebuild, if a user sets USE="-mmx sse2", I actually > _disable_ both MMX and SSE2 support because it doesn't make any sense. > I don't think user will like having kontact disabled because he had to enable kde to get it working. I mean, even if a warning is shown, he probably see it at the end of the emerge process. If kontact was a key feature, he will have to rebuild ekiga. mmx and sse2 are not things that make you rebuild a package for, they are not features so you can consider them as not important enough to silently disable them. Anyway, I think EAPI-3 pretend will make it clearer and I will try to add a feature to EAPI-4 to really manage this kind of USE flags restrictions. I will leave this bug open as a reminder.
Too much devs were complaining. Behavior has changed.
