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.
]]>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.
]]>all inclusive or not you will get broken packages on occasion.
]]>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?
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.
]]>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.
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.
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
]]>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.
]]>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
]]>_________________
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.
]]>