Libreoffice and kde integration

[Michael Meeks]

Hi Bjoern,

On Tue, 2013-12-24 at 01:27 +0100, bjoern wrote:
> Ah, I finally get what you were up too with that kde-stub-libs-foo. ;)

	Right - and it -should- almost work; just needs a little more work to
get (IIRC) some ELF objects working nicely - but I ran out of time
sadly.

> Just brainstorming, I wonder if it would be easier to do roughly what distros do
> in these cases, for the 'integration' parts of LibreOffice that connect with
> other infrastructure on the OS (mostly the above mentioned kde/gtk/gnome-foo),
> namely: simply using a newer baseline.

	I'm not that clear on what you suggest. I assume you are not suggesting
doubling the number of Linux packages to 4x per architecture: .deb
+ .rpm (old) and .deb + .rpm (new) - and then more fooling in the
downloader etc. ? (that doesn't sound sensible for a minority platform -
with x86_64 -> 8x package archives.

	An alternative meaning: we can certainly try to install newer software
eg. KDE4 on the old system - and compile vs. that: that is almost no
issue at all. We have dynamic hooks and conditionals, and demand loading
for all that. If we -could- compile it on that machine we could do that.

	Problem is - from a raw 'package' perspective; you can't just install
"KDE-devel" and expect it to work; each library brings a slew of other
libraries, all of which start to try to do very heavy lifting on the
platform: the dependencies go down to the bottom - new versions of
'hal', 'systemd', 'udev' you name it - the desktop has -very- long
roots. Of course - it's probably possible to re-compile all of that
ourselves for CentOS5 - but - that's a huge chunk of work. If someone
wants to do it and maintain it they are more than welcome.

	My hope was that by building (dependency free) stub libraries from an
existing (newer system's gio* and KDE*) we could install that stuff as
pure stubs with no dependencies at all - we could whack the headers in,
along with these libs, check our linking is ok, and just ship that lot.
There is never a need to run anything that links to them during compile.

> Now using two baselines, one for 'core' LibreOffice which is truely ancient and
> one for system integration, which is more recent, and building parts of
> LibreOffice in each can be assumed to sounds like madness and probably is. Im
> just not sure if using some symbols stubs lib approach is less painful in the
> end.

	Well - from a dependency perspective; having a 'libfoo.so' that has no
other library dependencies, and just exports stubs that match the real
'libfoo.so' is extremely elegant.

> P.S.: Note that the 'use two baselines' thing is likely easier than it sounds
> as tools like pbuilder are around and automate most of that away.

	OBS builds ~everything inside a similar chroot which it will
auto-populate for you; but there is some significant grief around the
mechanics of double building ~everything and then shuffling bits of it
around into a single install set I suspect. I suspect it'd be better to
use OBS to try to re-build all of glib<next> and KDE<next> on CentOS5 if
someone is desperate for that, or failing that - finishing & testing the
stubber ;-)

	But it's your baby ... ;-)

	ATB,

		Michael.

-- 
 michael.meeks at collabora.com  <><, Pseudo Engineer, itinerant idiot