Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 361695 - [app-office/libreoffice-bin] completely rework the package or drop it due to bundling everything you can think of
Summary: [app-office/libreoffice-bin] completely rework the package or drop it due to ...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Office Team
URL:
Whiteboard:
Keywords:
: 230622 253727 299200 328799 363835 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-04-02 16:26 UTC by Nirbheek Chauhan (RETIRED)
Modified: 2012-02-25 15:44 UTC (History)
18 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nirbheek Chauhan (RETIRED) gentoo-dev 2011-04-02 16:26:43 UTC
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!
Comment 1 Nirbheek Chauhan (RETIRED) gentoo-dev 2011-04-04 12:57:44 UTC

*** This bug has been marked as a duplicate of bug 317425 ***
Comment 2 Nirbheek Chauhan (RETIRED) gentoo-dev 2011-04-04 12:58:09 UTC
Oops, accidental duplication.
Comment 3 Tomáš Chvátal (RETIRED) gentoo-dev 2011-07-26 20:57:06 UTC
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 :)
Comment 4 Tomáš Chvátal (RETIRED) gentoo-dev 2011-07-26 21:16:44 UTC
*** Bug 253727 has been marked as a duplicate of this bug. ***
Comment 5 Tomáš Chvátal (RETIRED) gentoo-dev 2011-07-26 22:26:44 UTC
*** Bug 230622 has been marked as a duplicate of this bug. ***
Comment 6 Tomáš Chvátal (RETIRED) gentoo-dev 2011-07-26 23:01:26 UTC
*** Bug 328799 has been marked as a duplicate of this bug. ***
Comment 7 Andreas Proschofsky (RETIRED) gentoo-dev 2011-07-27 11:24:04 UTC
(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)
Comment 8 Tomáš Chvátal (RETIRED) gentoo-dev 2011-07-27 12:09:35 UTC
*** Bug 299200 has been marked as a duplicate of this bug. ***
Comment 9 Tomáš Chvátal (RETIRED) gentoo-dev 2011-07-27 12:11:06 UTC
*** Bug 363835 has been marked as a duplicate of this bug. ***
Comment 10 Tomáš Chvátal (RETIRED) gentoo-dev 2011-07-28 14:19:51 UTC
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.
Comment 11 Mike Thompson 2011-08-04 20:23:15 UTC
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.
Comment 12 Martin Väth 2011-08-05 19:20:35 UTC
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?
Comment 13 Sergiy Borodych 2011-10-27 14:16:57 UTC
Are you planned version without cups?
 (and more then 20 deps on desktop and 30 deps on netbook for me :()
Please do it.
Comment 14 Richard H. 2011-10-27 14:21:32 UTC
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?
Comment 15 Tomáš Chvátal (RETIRED) gentoo-dev 2011-10-27 16:16:23 UTC
(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.
Comment 16 Richard H. 2011-10-27 16:25:30 UTC
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 :)
Comment 17 Tomáš Chvátal (RETIRED) gentoo-dev 2011-10-27 16:29:21 UTC
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).
Comment 18 Richard H. 2011-10-27 16:37:46 UTC
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 :)
Comment 19 Raphaël Droz 2011-10-28 10:36:12 UTC
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 !
Comment 20 Paweł Rumian 2012-02-02 14:50:54 UTC
(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...
Comment 21 Andreas K. Hüttel gentoo-dev 2012-02-25 15:44:37 UTC
(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... :)