On Tue, 2015-07-21 at 03:11 +0100, Alberto Ruiz wrote: > Another problem I didn't mention which is that sometime the checkout > dir makes "make" go bonkers at some point even with jhbuild build > -fac. It is quite often that I update my jhbuild setup after ages of > not touching it and I have to basically "rm -rf * && git reset - > -hard" and configure again to get the build going again. Given how > long it takes to jhbuild everything this is another extremely > annoying point that we can't ensure won't hit people. You can't leave > the thing building and go make a coffee, you have to work for the > automation system instead of the other way around. It is really a > disaster if you ask me that we enforce this on every GSoC student :/
Perhaps the ideal solution would be to decouple the dependencies. When I'm trying to fix up some mail protocol back end in Evolution, I really *shouldn't* need to upgrade my entire system to the very latest glib/gtk+ and then upgrade a whole bunch of *applications* which for some reason don't work with the new libraries. In this thread we're talking about tooling to *help* me set up a container with that full set of upgraded stuff, but we seem to be missing the point that in an ideal world I shouldn't need it at all. (It doesn't help that we don't have symbol versioning, so the distro packaging has a lot of dependencies wrong, of course. So just running 'dnf --releasever=rawhide update gnome-foo' tends to break.) I often actually find myself testing on the *stable* branch of evolution-data-server, then committing blindly to master. Which is entirely the wrong way round. -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
