dev-libs/libgdata is the only package that requires net-libs/gnome-online-accounts, all other packages play nice and include it conditionally on an USE flag appropriately named gnome-online-accounts. This would allow many users to be able to get rid of the troubling webkit-gtk (requires ruby, long build times, a lot of bugs).
This is present in the ebuild:
$(use_enable gnome) \
$(use_enable gnome goa) \
which I think should not be so, but goa should be conditional even one level deeper on the use flag gnome-online-accounts.
I agree with this change however it seems USE=gnome is misleading here for the rest of the features as well. According to configure.ac and as confirmed by reading the code, --enable-gnome enables password retrieval using gcr APIs which avoids leaking the passwords to pageable memory. As such it should be either renamed to USE=crypt or enabled always altogether. Moving gnome-online-accounts to its own USE flag would then be a no brainer.
May I add that the chain to webkit-gtk can be broken earlier, see my other bug:
Looks like upstream splitted goa support for this purpose of avoiding webkit-gtk dep, then, adding the gnome-online-accounts USE flag would be ok
Regarding renaming "gnome" to "crypt", I don't mind :/ (well, we need to remember to put a REQUIRED_USE statement to ensure gnome-online-accounts USE requests gnome/crypto USE)
Yes, it is annoying because it means we need to add || ( gcr[crypto] gcr[gnome] ) in most ebuilds using it but I can take care of that. I will try to find other optional usage of gcr and see with upstream if changing the name of the configure switch is relevant for them too.
Well, if we rename libgdata[gnome] to libgdata[crypto] it looks like only a few ebuilds will be affected
As we are now forced per policy to revbump when changing RDEPENDs like this, I would simply move the deps to libgdata[crypto] instead of || ( libgdata[gnome] to libgdata[crypto] ) to prevent we needing to revbump again when libgdata[gnome] disappears in the future and also strange blockers that could arise when people mix some packages from testing and stable
So, if I understand correctly, this referenced bug just shows this split of gnome USE flag to two separate "crypt" and "goa" is even more urgently needed.
It shows there is a need for a more fine-grained control yes, but there is nothing urgent about it. Given the extent of changes needed it won't be done in a flick of a finger anyway.
See this, it is urgent.
There is a need to deal away with this horrendous piece of software.
No, you have the needed controls already, even though they are not perfect.
(In reply to Gilles Dartiguelongue from comment #9)
> No, you have the needed controls already, even though they are not perfect.
Also, from the quick check I had earlier with #-security, we are fine with 2.10.4.
Fixed in -r1