On Mon, Mar 23, 2015 at 4:36 PM, Dimstar / Dominique Leuenberger
On Mon, 2015-03-23 at 16:21 +0100, Dinar Valeev wrote:
GNOME does not depend on mono.. but a couple of libraries do offer bindings and, yes, it IS worthy to provide this stuff.
if you really want to split this out, then the way would be to build the same library twice: once with mono and then a 2nd .spec file which only builds the mono bindings.. but you will waste much more build cycle, so not worth it at all (especially as most libs will not allow to 'only build the bindings' - the core component always need to be built and in case of the 2nd .spec file be ignored. This is done for example in libproxy/libproxy-plugins So, IIUC
We want to build bindings with Mono by default for KDE to be prepared to the fact some user will come and build 'third party' against libkolabxml. And we want to be prepared for that.
for GNOME we want this for banshee and tomboy?
for GNOME is not exactly correct, but I know what you mean.
Various GNOME libraries must provide bindings for tomboy, gnome-do banshee and certainly others (gmime's mono bindings for example are needed by tomboy - and possibly stuff outside our distribution).
For graphviz: what harm does it cause, that a dependency for libzypp might provide mono bindings (ok, it means libzypp will be ordered a bit further down the chain, as mono must be before graphviz). THIS could be addressed with a 2nd .spec file, as I outlined earlier (1st spec file doing graphviz-mini doing only the 'bare minimum' and graphviz.spec doing the 'full set')
For ppcle64, which essentially your goal, I'd rather have the prjconf set for this project to not do mono bindings, if fixing mono is really not in reach (anybody talked with mono upstream here?) But disabling for all archs 'just because of ppcle64' is rude :) I already have in place prjconf and I'm on the way of fixing mono for LE.
Again.. This is not about it is broken for ppc64le. It is about we have to rebuild this again and again in stagings. I took it as general Factory optimization. To have fixes going though faster. Yes. My main working area is Power. But this doesn't mean I'll ask to drop any stuff doesn't build for me yet.
Cheers, Dominique
-- Dimstar / Dominique Leuenberger
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org