|Summary:||gnome-base/gnome-shell: Obey USE="eds" and make gnome-extra/evolution-data-server optional|
|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-12-13 22:43:40 UTC
This in turn makes a chain reaction of *mandatory* bloated dependencies, which means it cannot be broken with any USE flag at any point. gnome-base/gnome-shell gnome-extra/evolution-data-server dev-libs/libgdata net-libs/gnome-online-accounts net-libs/webkit-gtk <---- (critical, compile time of few hours) dev-lang/ruby <--- (not a delicacy either) Arch Linux somehow manages to make it optional. https://www.archlinux.org/packages/extra/x86_64/evolution-data-server/ Reproducible: Always Steps to Reproduce: 1. Put -eds to make.conf Actual Results: The system takes 10 additional hours to compile. Expected Results: gnome-extra/evolution-data-server is not pulled at all, breaking the chain. I consider this pretty major.
Comment 1 Gilles Dartiguelongue 2015-12-13 23:12:09 UTC
I am not sure if I like this but it appears to be possible to make it optional indeed. The shell makes calls to eds through an application that is loaded via dbus. If initialization fails, it appears to be non-fatal for gnome-shell, it will register to be aware of the service launch if it appears later on. @gnome, what do you guys think about this ?
Comment 2 Gilles Dartiguelongue 2015-12-13 23:12:41 UTC
Location of interest for this: js/ui/calendar.js src/Makefile-calendar-server.am
Comment 3 Rok Kralj 2015-12-14 09:52:52 UTC
Well, since the global use flag "eds" already exists, it is only logical that it works everywhere. So, I would suggest we add that use flag and make it default, +eds.
Comment 4 Pacho Ramos 2015-12-14 12:28:40 UTC
I am against adding more "unofficial" patches to make more things optional leading that setups to be unsupported by upstream and also harder to bump when major changes are committed by them and we need to update the patches (and probably even patch more and more files as upstream rely on eds more)
Comment 5 Pacho Ramos 2015-12-14 12:31:05 UTC
(In reply to Rok Kralj from comment #0) > This in turn makes a chain reaction of *mandatory* bloated dependencies, > which means it cannot be broken with any USE flag at any point. > > gnome-base/gnome-shell > gnome-extra/evolution-data-server Also this chain is due to bug 566324 > dev-libs/libgdata > net-libs/gnome-online-accounts > net-libs/webkit-gtk <---- (critical, compile time of few hours) > dev-lang/ruby <--- (not a delicacy either) >
Comment 6 Rok Kralj 2015-12-14 15:21:09 UTC
Pacho ramos, since this is a runtime dependency, there is no offtree patch needed. Just change this: >=gnome-extra/evolution-data-server-3.17.2:= to this: eds? ( >=gnome-extra/evolution-data-server-3.17.2:= )
Comment 7 Gilles Dartiguelongue 2015-12-14 23:47:53 UTC
@rok No this is not a runtime dependency, it needs a component of gnome-shell to be built first. Having USE flags for things in gentoo tree does not mean every packages under the sun have to or can support them. @pacho I agree that this is one more patch but this particular one seems lightweight to me compared to some other monsters we carry in gnome-control-center for example.
Comment 8 Pacho Ramos 2015-12-15 10:11:11 UTC
@eva, of course :), my main concern was about maybe we in the future needing to make the patch grow more and more because upstream won't care about they relying more on eds (as they will assume it's installed unconditionally). Also, it looks like reintroducing gnome-online-accounts USE flag for libgdata (bug 566324) would solve most of this dependency bloat and, then, this would be unneeded, but maybe I am losing something :/ I would opt for fix bug 566324 and that should also solve this one. My only doubt in that bug is about taking advantage of that change to also rename its "gnome" USE flag to "crypto" (I don't mind either option there)
Comment 10 Gilles Dartiguelongue 2015-12-30 23:57:37 UTC
I don't want to completely rule out this bug yet. I will have a look at the patch and submit it here.