OpenOffice needs libart-lgpl package

PipoDeClown · 2004-01-13 20:48:26

the libart-lgpl package should be installed too when installing openoffice, else you get an error about missing libartlgpl library.

sarah31 · 2004-01-13 21:13:12

please file a bug report.

PipoDeClown · 2004-01-13 21:27:37

done..., ty for pointing out the right way

Xentac · 2004-01-13 22:43:55

Openoffice depends on gtk2, which depends on librsvg, which depends on libart-lgpl. That dependency should already be satisfied. Make sure you have the newest versions of everything and please follow-up your bug report.

PipoDeClown · 2004-01-14 01:43:02

First i only installed xfree86, windowmaker and mozilla-firebird. After that worked fine Openoffice. All on a freshly installed platform (and updated pacman and -Syu ofcourse).

hApy · 2004-01-14 07:52:40

PipoDeClown wrote:

_________________
why does archlinux reminds me of downloading linux 0.98 (slackware) on 40 floppies over 14k4?.

errr... why DOES it remind you of that?

just curious what you mean

Hapy.

neri · 2004-01-14 10:14:22

Hi Xentac,

Xentac wrote:

Openoffice depends on gtk2, which depends on librsvg, which depends on libart-lgpl. That dependency should already be satisfied. Make sure you have the newest versions of everything and please follow-up your bug report.

isn't true anymore. Things have changed according to a crcular dependency
AFAIR. Now librsvg depends on gtk2, though I've heared it's actually a
makedpends only. Didn't have the time to investigate that.

bye neri

Bobonov · 2004-01-14 12:22:43

This is a dep problem related to tools (package) evolution.
I saw that most of the time people put as dependencies only the "main" package because in it there is already the dependencies to another.
This is a bit dangerous since software change and evolve in time and sometime it start to relay on othe software/libs.
In order to have "safer" package is better to put all dependecies instead relaying on other package dependencies.
I know that this lead to long deps list but is much more better than having an error for missing libs.
For instance these are the dependencies in openoffice pkg
'gcc' 'xfree86' 'pam' 'gtk2'
Each of them
gcc --> bash binutils glibc
xfree86 --> fontconfig freetype1 gcc glibc ttf-bitstream-vera
pam --> filesystem glibc
gtk2 --> atk freetype2 glib2 libjpeg libpng librsvg libtiff libungif
pango xfree86

And we can go down to the other

But if I start to use ldd on openoffice I obtain the following

expat, gcc, xfree86, db, gtk2, libart-lgpl, freetype2, glibc, tcl, pango, gmp, fontconfig, ncurses, zlib, glib2, tk, gdbm, atk, openssl, readline

Without going too deep.......

Now just for example tomorrow for some reason one of the above pkg dep of open office stop to use something that openoffice need we have a broken pkg.

neri · 2004-01-14 14:02:06

Hi Bonobov,

Most recently I ran into a very similar problem working on the xfce4 repo.
The dependency chain gtk2->librsvg->libxml was broken. Xfce4 make usage
on xml styled rc files and dependencies were broken.

Bobonov wrote:

In order to have "safer" package is better to put all
dependecies instead relaying on other package dependencies. I know that
this lead to long deps list but is much more better than having an error
for missing libs.

The question is, do we have guidelines on this? On the one hand, these deps
easily can be found by namcap. On the other hand running namcap on every
package that eats maintainers time.
Personally I like the idea of small dependency lists.

just my 2 cent.

bye neri

Bobonov · 2004-01-14 15:13:15

The question is, do we have guidelines on this?

I think there are no clear guideline about that, I think is a decision up to the developer to decide the policies on how to write dependencies.

On the one hand, these deps easily can be found by namcap. On the other hand running namcap on every package that eats maintainers time.
Personally I like the idea of small dependency lists.

Personally I would prefr to have stable package with long dep list than having it broken.
I use arch linux in production enviroment and I realy do not want to discover that something stops to work due to a missing library.
Naturally I do not refer to openoffice and I don't mind if xfce stop to work, but to other software like apache, sshd, exim...
I administer more than 3 server with archlinux remotely, their installation has only the minimum to do their work, what happen if next version of sshd is broken? How can I remotely acces to the computer to fix the problem?

Probably it is not necessary to have the complete dep list on all package but at least we need it on some core package.
All daemons
All core library
Anyway if archlinux want to compete with other distribution at first it should provide error free package.
Ok for sure bugs always happen but this of the deps can be solved by doing a long deps list.

Xentac · 2004-01-14 15:58:25

neri wrote:

isn't true anymore. Things have changed according to a crcular dependency AFAIR. Now librsvg depends on gtk2, though I've heared it's actually a makedpends only. Didn't have the time to investigate that.

So it was updated, no one told me, and my packages weren't updated? I'm running an up to date system and verified what I was saying right before posting. Can you show me otherwise?

Bobonov wrote:

I think there are no clear guideline about that, I think is a decision up to the developer to decide the policies on how to write dependencies.

What we have here is a conflict of ideals. I've explained this before and every time someone has asked. Maybe we should come to an agreement as developers on this one...

This is the way I see dependencies. If a library is linked directly to a program because it uses a function from that library it's said to have a first level dependency. If a program links to something only because one of its libraries links to it, then it's a second level dependency.

First level dependencies should be included. Second level should not. Namcap tries to figure out the first level dependencies but only has ldd to go off of. You could say that namcap is the guideline.

I think that getting dependencies right is a better solution than getting them "complete". A big long list is unmanageable and not all that nice looking. Dependencies are supposed to be helpful and simple, otherwise they become more work than they're worth.

Xentac · 2004-01-14 16:12:49

So it looks like the package was updated and no one did tell me... Abs tells me that librsvg isn't a dep, but re-installing the package keeps the dep there. I'll see what I can do to figure it out...

sarah31 · 2004-01-14 16:20:05

the problem too with including all of the dpendencies instead of just first level is that you WILL get unsolvable dependency loops. anyone who has used debian will have experienced this. while many claim that debian is very stable because of this i tend to disagree. debians massive dependency list can sometimes result in hundreds of megabytes of packages being removed when one calls for apt to remove ONE small package. i once asked apt to remove one small app i did not use anymore and because they include every dependency i would have basically had to rebuild my entire gui desktop.

all inclusive or not you will get broken packages on occasion.

sarah31 · 2004-01-14 16:23:54

Xentac wrote:

So it looks like the package was updated and no one did tell me... Abs tells me that librsvg isn't a dep, but re-installing the package keeps the dep there. I'll see what I can do to figure it out...

as i said in another thread gtk2 DOES NOT require librsvg either to build or to run. However, librsvg does require gtk2 to build. when i was build ing i586 i ran into this issue because neither gtk2 or librsvg would build because each "depended" on the other.

you will find that "-Qi" is not very reliable in its dependency lists.

Xentac · 2004-01-14 16:53:34

sarah31 wrote:

you will find that "-Qi" is not very reliable in its dependency lists.

-Qi should be giving information taken from the package that was installed. The information in the package may be different than the information in the repo. I believe that's where problem comes in. Dorphell is looking at it now.

sarah31 · 2004-01-14 18:11:34

yeah it should but there has been more than one time that i have not gotten the right information from pacman -Qi. more often than not it is with regard to what depends on whatever package you are getting info on (that is what uses it as a depend not what it depends on).

Blaasvis · 2004-01-15 09:17:00

i am adding libart-lgpl now to the package, so the bug will be fixed.

Arch Linux

#1 2004-01-13 20:48:26

OpenOffice needs libart-lgpl package

#2 2004-01-13 21:13:12

Re: OpenOffice needs libart-lgpl package

#3 2004-01-13 21:27:37

Re: OpenOffice needs libart-lgpl package

#4 2004-01-13 22:43:55

Re: OpenOffice needs libart-lgpl package

#5 2004-01-14 01:43:02

Re: OpenOffice needs libart-lgpl package

#6 2004-01-14 07:52:40

Re: OpenOffice needs libart-lgpl package

#7 2004-01-14 10:14:22

Re: OpenOffice needs libart-lgpl package

#8 2004-01-14 12:22:43

Re: OpenOffice needs libart-lgpl package

#9 2004-01-14 14:02:06

Re: OpenOffice needs libart-lgpl package

#10 2004-01-14 15:13:15

Re: OpenOffice needs libart-lgpl package

#11 2004-01-14 15:58:25

Re: OpenOffice needs libart-lgpl package

#12 2004-01-14 16:12:49

Re: OpenOffice needs libart-lgpl package

#13 2004-01-14 16:20:05

Re: OpenOffice needs libart-lgpl package

#14 2004-01-14 16:23:54

Re: OpenOffice needs libart-lgpl package

#15 2004-01-14 16:53:34

Re: OpenOffice needs libart-lgpl package

#16 2004-01-14 18:11:34

Re: OpenOffice needs libart-lgpl package

#17 2004-01-15 09:17:00

Re: OpenOffice needs libart-lgpl package

Board footer