libreoffice-bin seems to bundle far too many libraries in /usr/lib*/libreoffice/basis3.3/program . For some of them such as libicu*.so, libmozjs.so, libxpcom.so, etc, it does make sense because the soversion changes frequently, or the ABI is unstable. But for libraries with stable ABIs such as x11-libs/pixman, x11-libs/cairo, sys-libs/db:4.7, net-libs/neon, and many more, it makes absolutely no sense to bundle the libraries. Infact, bundling them causes problems in some instances such as: /usr/lib64/libreoffice/program/soffice.bin: symbol lookup error: /usr/lib64/libcairo.so.2: undefined symbol: pixman_image_composite32 Due to the bundled pixman not having that symbol, and libreoffice picking up the system-wide cairo instead of the bundled one. It is especially silly to bundle X libraries with a program — even OOo didn't stoop that far. Please add dependencies on at least *some* of these libraries instead of bundling them, thanks!
*** This bug has been marked as a duplicate of bug 317425 ***
Oops, accidental duplication.
So do you have some proposal how to handle binary libreoffice than using these -bin rpms provided by upstream? Given the overhaul i did in lo-3.4.2.2 where i crushed the compile time to 1 hour it might be even usefull to drop the binary as whole :)
*** Bug 253727 has been marked as a duplicate of this bug. ***
*** Bug 230622 has been marked as a duplicate of this bug. ***
*** Bug 328799 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > > Given the overhaul i did in lo-3.4.2.2 where i crushed the compile time to 1 > hour it might be even usefull to drop the binary as whole :) As much as I would like to do this: I don't think this is realistic for everyone. My build time is about ~45 minutes now (not taking in account all the dependencies obviously ;) ), but this is a pretty fast machine and unfortunately I think there are still a lot of people for whom it still takes multiple hours to build LibreOffice (not even talking about the diskspace it consumes while doing this)
*** Bug 299200 has been marked as a duplicate of this bug. ***
*** Bug 363835 has been marked as a duplicate of this bug. ***
The approach with the rpms is broken. So we need to find another one :) and i know that plain drop for the binaries would make people unhappy a lot. So the idea would be to grab our ebuild and build just some set of features (consume or die) :P lets just say to provide 6 flavors: -java -gtk -gnome -eds kde -java gtk -gnome -eds -kde -java gtk gnome eds -kde java -gtk -gnome -eds kde java gtk -gnome -eds -kde java gtk gnome eds -kde Rest with default profile useflags (no mysql, no fancy stuff like ldap...). This way we would cover most use cases and generating the binaries would take ~6 hours. -> this would be availible to download for users and recompiled again stable tree. Here the question stands what about the testing tree, but i would say if someone use testing he can as well compile libreoffice.
This may be too ambitious--or naive--but I have a different kind of proposal. How about an approach that is intermediate between the normal full build-from-source technique and the distribution of a finished binary? I'm assuming that the bigger part of the build time is from compiling rather than linking. Does a -bin package *have* to contain a finished binary ready for installation? Could it instead contain a set of static libraries ready for linking? The ebuild would choose the appropriate versions of the libraries to use as a function of the USE flags. Here's more of what I mean. Say that abc.o and def.o are pretty much invariant according to the USE flags and are always linked into the final binary. These would go into base.a. If ghi.o goes into the final binary according to a USE flag, but is itself otherwise invariant across the USE flags, it would also go into base.a. The more interesting cases--the ones I'm hoping occur only for a minority of the object modules--would be for the ones that take different forms according to the USE flags. These would have to go into separate .a files for the major USE-flag settings. This might mean that you'd need a kde.a and a gnome.a for modules that are compiled with KDE- or Gnome-specific directives. This would be to avoid symbol collisions within a single static library. The ebuild would then have to choose which of the libraries to pass to the linker for the final build. All this would avoid a big issue with prebuilt binaries with multiple options: a huge tarball with a binary for each permutation of major USE flags or a bunch of separate, small tarballs for each permutation. The user would get most of the flexibility we get with USE flags but without having to wait for everything to compile. The difficulty, as I can well appreciate, would be in figuring out how to construct the monster. I would think that in the course of building the package multiple times with changes in USE settings, the developer could run a script to find which of the .o files take on different forms according to the USE flags. This one part could be automated; I don't know about the other stages in getting this all to work.
As a user who uses libreoffice only very seldom, I vote for keeping the current state at least as an option for the user. In fact, especially on a laptop with low harddisk space, it is nice to keep the binary and unpack it only on the seldom occassions once or twice a year when it is needed. I would not like to install also ~20 partially huge packages (like sys-libs/db media-libs/vigra dev-libs/rasqal dev-libs/redland media-libs/raptor sys-libs/libieee1284 app-text/mythes etc, the list is not complete) for which I have no other use (and for which no binaries are provided) in such occassions or - even worse - to keep these huge dependencies installed permanently. What sense does it make to have the possibility with USE-flags to drop e.g. the dependency on e.g. sys-libs/db for most packages if there is one almost unavoidable (binary!) package which forces these anyway?
Are you planned version without cups? (and more then 20 deps on desktop and 30 deps on netbook for me :() Please do it.
Is it this bug, because of which I have to install now 20 or so java packages, openldap and so on? For now, I have package.mask'ed libreoffice 3.4.3, because it's really too much. However, I don't think that's Gentoo's fault in any way. If it keeps getting more and more fatty, I might simply drop it completely and look out for some alternative. Basically my single question is: Does this all have to be? Calculating dependencies ... done! [nomerge ] app-office/libreoffice-bin-3.4.3.2-r1 [3.3.4] USE="kde%* (-aqua) (-kdeenablefinal)" [ebuild N ] app-office/libreoffice-l10n-3.4.3-r3 USE="-offlinehelp" LINGUAS="de -af -ar -as -ast -be -bg -bn -bo -br -brx -bs -ca -ca_XV -cs -cy -da -dgo -dz -el -en -en_GB -en_ZA -eo -es -et -eu -fa -fi -fr -ga -gl -gu -he -hi -hr -hu -id -is -it -ja -ka -kk -km -kn -ko -kok -ks -ku -lo -lt -lv -mai -mk -ml -mn -mni -mr -my -nb -ne -nl -nn -nr -nso -oc -or -pa_IN -pl -pt -pt_BR -ro -ru -rw -sat -sd -sh -sk -sl -sq -sr -ss -st -sv -sw_TZ -ta -te -tg -th -tn -tr -ts -ug -uk -uz -ve -vi -xh -zh_CN -zh_TW -zu" [ebuild U ] app-office/libreoffice-bin-3.4.3.2-r1 [3.3.4] USE="kde%* (-aqua) (-kdeenablefinal)" [ebuild N ] dev-java/saxon-8.4b-r3 USE="-doc -examples -source" [nomerge ] dev-java/saxon-8.4b-r3 USE="-doc -examples -source" [nomerge ] dev-java/jdom-1.0-r4 USE="-doc -examples -source" [ebuild N ] dev-java/jdom-jaxen-1.0-r1 [ebuild N ] dev-java/jaxen-1.1.1 USE="-doc -examples -source -test" [ebuild N ] dev-java/jdom-1.0-r4 USE="-doc -examples -source" [nomerge ] app-office/libreoffice-bin-3.4.3.2-r1 [3.3.4] USE="kde%* (-aqua) (-kdeenablefinal)" [ebuild N ] media-libs/vigra-1.7.1-r1 USE="fftw hdf5 jpeg png python tiff -doc -test" [ebuild N ] sci-libs/hdf5-1.8.4-r1 USE="cxx fortran mpi threads zlib -examples -szip" [ebuild N ] dev-java/bsh-2.0_beta4-r3 USE="readline -bsf -doc -source" [ebuild N ] dev-java/libreadline-java-0.8.0-r3 USE="-doc -source" [nomerge ] dev-java/jaxen-1.1.1 USE="-doc -examples -source -test" [ebuild N ] dev-java/dom4j-1.6.1-r3 USE="-doc -source -test" [ebuild N ] dev-java/msv-20050627-r2 USE="-doc -source" [ebuild N ] dev-java/iso-relax-20050331-r1 USE="-source" [ebuild N ] dev-java/jsr173-1.0-r1 USE="-doc -source" [ebuild N ] dev-java/jaxme-0.5.2 USE="-doc -source" [ebuild N ] dev-db/hsqldb-1.8.1.2-r1 USE="-doc -source -test" [ebuild N ] java-virtuals/servlet-api-2.3 [ebuild NS ] dev-java/tomcat-servlet-api-4.1.36 [6.0.32] USE="-doc -source" [ebuild N ] dev-java/log4j-1.2.16 USE="-doc -javamail -jms -jmx -source" [ebuild N ] dev-java/antlr-2.7.7-r2 USE="cxx java -debug -doc -examples -mono -python -script -source -static-libs" [ebuild N ] dev-java/xmldb-20011111-r1 USE="-doc -source" [ebuild N ] dev-java/xpp2-2.1.10-r1 USE="-doc -source" [ebuild N ] dev-java/xpp3-1.1.4c-r1 USE="-doc -source -test" [nomerge ] app-office/libreoffice-bin-3.4.3.2-r1 [3.3.4] USE="kde%* (-aqua) (-kdeenablefinal)" [ebuild NS ] dev-java/lucene-2.9.4 [1.9.1] USE="-doc -source -test" [ebuild N ] dev-java/javacc-4.0-r4 USE="-doc -examples -source -test" [ebuild NS ] dev-java/lucene-analyzers-2.3.2 [1.9.1-r1] USE="-source" [nomerge ] dev-java/dom4j-1.6.1-r3 USE="-doc -source -test" [ebuild N ] dev-java/xsdlib-20050627-r2 USE="-doc -source" [nomerge ] dev-java/jdom-jaxen-1.0-r1 [nomerge ] dev-java/jdom-1.0-r4 USE="-doc -examples -source" [ebuild N ] dev-java/saxpath-1.0-r2 USE="-doc -source -test" [nomerge ] dev-java/saxon-8.4b-r3 USE="-doc -examples -source" [ebuild N ] dev-java/xom-1.2.6 USE="-doc -examples -source" [nomerge ] dev-java/dom4j-1.6.1-r3 USE="-doc -source -test" [ebuild N ] dev-java/relaxng-datatype-1.0-r1 USE="-doc -source" [nomerge ] sci-libs/hdf5-1.8.4-r1 USE="cxx fortran mpi threads zlib -examples -szip" [ebuild N ] sys-process/time-1.7-r1 [nomerge ] app-office/libreoffice-bin-3.4.3.2-r1 [3.3.4] USE="kde%* (-aqua) (-kdeenablefinal)" [ebuild N ] net-nds/openldap-2.4.24 USE="berkdb crypt gnutls ipv6 minimal samba ssl tcpd -cxx -debug -experimental -icu -iodbc -kerberos -odbc -overlays -perl -sasl (-selinux) -slp -smbkrb5passwd -syslog" [ebuild N ] dev-db/unixODBC-2.3.0-r1 USE="minimal -odbcmanual -static-libs" [ebuild N ] sci-mathematics/lpsolve-5.5.2.0 USE="-static-libs" [ebuild N ] sci-libs/colamd-2.7.1 USE="-static-libs" [ebuild N ] sci-libs/ufconfig-3.5.0 USE="-static-libs" [ebuild N ] app-text/libwpg-0.2.1 USE="-doc -static-libs" [ebuild N ] app-text/libwps-0.2.3 USE="-debug -doc -static-libs" [ebuild N ] media-gfx/graphite2-1.0.3 USE="-perl -test" [ebuild N ] dev-libs/hyphen-2.7.1 [ebuild N ] app-text/mythes-1.2.1 USE="-static-libs" [ebuild N ] app-text/libwpd-0.9.3 USE="tools -doc -test" Or are those packages really small/slim?
(In reply to comment #14) > Is it this bug, because of which I have to install now 20 or so java packages, > openldap and so on? For now, I have package.mask'ed libreoffice 3.4.3, because > it's really too much. However, I don't think that's Gentoo's fault in any way. > If it keeps getting more and more fatty, I might simply drop it completely and > look out for some alternative. > > Basically my single question is: Does this all have to be? > > Or are those packages really small/slim? Why can't you use -java if you find this that huge? If you want java enabled it pulls all the required java packages... Cups is hard dependency, it can't be removed. Openldap is optional, yet default in desktop profiles so it is on by default. Again, if you disagree with what the thing is pulling you can always compile it yourself without any enabled useflags. (In reply to comment #13) > Are you planned version without cups? > (and more then 20 deps on desktop and 30 deps on netbook for me :() > Please do it. If you disagree with what useflags I set you are free to generate more builds. Currently it takes 7-8 hours to generate one arch, so I spent day generating them both for you, so do you think I can afford compiling more flavors... The howto for the builds: http://blogs.gentoo.org/scarabeus/2011/10/17/libreoffice-binary-package/ The -java -kde -gnome version pulls this dependencies: dev-db/unixODBC selected: 2.3.0-r1 protected: none omitted: none media-gfx/graphite2 selected: 1.0.3 protected: none omitted: none app-office/libreoffice-l10n selected: 3.4.3-r3 protected: none omitted: none sci-mathematics/lpsolve selected: 5.5.2.0 protected: none omitted: none app-text/libwpg selected: 0.2.1 protected: none omitted: none app-text/libwps selected: 0.2.3 protected: none omitted: none app-text/mythes selected: 1.2.1 protected: none omitted: none dev-libs/hyphen selected: 2.8.3 protected: none omitted: none app-arch/zip selected: 3.0-r1 protected: none omitted: none media-libs/vigra selected: 1.7.1-r1 protected: none omitted: none net-nds/openldap selected: 2.4.25-r1 protected: none omitted: none dev-libs/redland selected: 1.0.14 protected: none omitted: none sci-libs/hdf5 selected: 1.8.7 protected: none omitted: none dev-libs/rasqal selected: 0.9.27 protected: none omitted: none sci-libs/colamd selected: 2.7.3 protected: none omitted: none sci-libs/fftw selected: 3.3-r1 protected: none omitted: none app-text/libwpd selected: 0.9.3 protected: none omitted: none media-libs/raptor selected: 2.0.4 protected: none omitted: none So I would say it is not that rough to you. Most of the packages are 1 meg libraries to handle various formats or specific types like rtl support.
Hey, Sorry I didn't want to offend you, or anyone in here. I was just a bit upset, and well, I didn't see the java USE-Flag. I will try it that way then. Like I said, I don't really think it's Gentoo's "fault". LOo just got quite huge by now :)
Well the problem is that ALL the above applications were in the binary before, they were also in archaic versions, so now you get even better working office suite if you use binary :) @Richard: No offense taken I just try to explain that we can't accomodate everyone and that it is possible to help fellow users by generating them for the arches you desire (i just dont want to pay such huge electricity bill).
Well, after having taken a look at the source ebuild (the not -bin), I think I will try to roll myself one. I tried that a long time before, and I do my own chromium builds too so it should be doable. All in all I don't need LDAP and rtl and who knows what else there is in there also, and you are right, the way it was (with the bundled libs) is really horrible, And maybe this change eben helps raise the awareness of people, what there was on their systems all the time with the binary version. That said, I normally really DO dislike packaged libs, XBMC is a very good example for this. But they use heavily patched libs, I didn't know libreoffice was packaging so much - until now. By the way if someone is interested in my as minimal-as-possible-kde packages, just drop me a line. No problems with sharing them :)
Could we expect libreoffice to be split into distinct "writer", "calc", "draw", ... in the future ? I think that lpsolve, openldap, unixODBC + the RDF stuff, ... are not needed for a simple Lowriter user. PS:thx for the -bin packages !
(In reply to comment #19) > Could we expect libreoffice to be split into distinct "writer", "calc", "draw", > ... in the future ? > I think that lpsolve, openldap, unixODBC + the RDF stuff, ... are not needed > for a simple Lowriter user. I would also wholeheartedly vote for this idea...
(In reply to comment #19) > Could we expect libreoffice to be split into distinct "writer", "calc", "draw", > ... in the future ? > I think that lpsolve, openldap, unixODBC + the RDF stuff, ... are not needed > for a simple Lowriter user. > > PS:thx for the -bin packages ! I think this is not really doable, afaik it's not supported by upstream build system and would really be a lot of work. You could try to get SuSE pay Tomas to do it though :D ... Anyway... As far as I can see it we're all set here, as the new binpackages are up and running. And please remember, you can always set useflags "java kde gnome" according to your personal preferences... :)
