|Summary:||dev-libs/libgdata: make gnome-online-accounts controllable by its own USE flag|
|Product:||Gentoo Linux||Reporter:||Rok Kralj <gentoo>|
|Component:||[OLD] GNOME||Assignee:||Gentoo Linux Gnome Desktop Team <gnome>|
|Package list:||Runtime testing required:||---|
Description Rok Kralj 2015-11-20 11:29:24 UTC
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: gnome2_src_configure \ $(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.
Comment 1 Gilles Dartiguelongue 2015-12-13 21:41:36 UTC
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.
Comment 2 Rok Kralj 2015-12-13 22:46:18 UTC
May I add that the chain to webkit-gtk can be broken earlier, see my other bug: https://bugs.gentoo.org/show_bug.cgi?id=568196
Comment 3 Pacho Ramos 2015-12-14 15:36:18 UTC
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) https://bugzilla.gnome.org/show_bug.cgi?id=690225
Comment 4 Gilles Dartiguelongue 2015-12-16 08:12:27 UTC
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.
Comment 5 Pacho Ramos 2015-12-16 11:15:13 UTC
Well, if we rename libgdata[gnome] to libgdata[crypto] it looks like only a few ebuilds will be affected gnome-base/gvfs/gvfs-1.26.2.ebuild: >=dev-libs/libgdata-0.17.3:=[gnome] gnome-extra/gnome-documents/gnome-documents-3.16.4.ebuild: >=dev-libs/libgdata-0.13.3:=[gnome,introspection] gnome-extra/gnome-documents/gnome-documents-3.18.2.ebuild: >=dev-libs/libgdata-0.13.3:=[gnome,introspection] net-misc/gnome-online-miners/gnome-online-miners-3.14.3.ebuild: >=dev-libs/libgdata-0.15.2:0=[gnome] net-misc/gnome-online-miners/gnome-online-miners-3.14.3-r1.ebuild: >=dev-libs/libgdata-0.15.2:0=[gnome] 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
Comment 6 Rok Kralj 2015-12-23 12:29:58 UTC
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.
Comment 7 Gilles Dartiguelongue 2015-12-23 23:24:50 UTC
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.
Comment 8 Rok Kralj 2015-12-28 21:17:32 UTC
See this, it is urgent. http://www.phoronix.com/scan.php?page=news_item&px=WebKit-2015-Vulnerabilities There is a need to deal away with this horrendous piece of software.
Comment 9 Gilles Dartiguelongue 2015-12-28 22:55:32 UTC
No, you have the needed controls already, even though they are not perfect.
Comment 10 Gilles Dartiguelongue 2015-12-28 22:57:29 UTC
(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.
Comment 11 Pacho Ramos 2015-12-30 10:24:53 UTC
Fixed in -r1