| Summary: | gnome-vfs 1.0.5-r3 ebuild's RDEPEND variable possibly incorrectly defined. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Kris Kelley <skunkworx> |
| Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED INVALID | ||
| Severity: | minor | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
No this isn't harmful. I don't know how it came to be, but it should just disregard the parenthesis. The revdep rebuild without the precise errors and order i can't say much about, but I don't think this is of any influence. It is possible that the revdep-rebuild failed for other reasons, but I still wanted to determine whether this was a factor. Thanks. |
The ebuild for gnome-vfs 1.0.5-r3 contains this definition for RDEPEND: RDEPEND="( =gnome-base/gconf-1.0* ) >=gnome-base/gnome-libs-1.4.1.2 >=gnome-base/gnome-mime-data-1.0.1 >=app-arch/bzip2-1.0.2 ssl? ( dev-libs/openssl )" Note that the gconf dependency has parentheses around it, yet does not use a conditional like the openssl dependency does. Is this a bug? I did not see any formatting rules in the ebuild(5) man page that would match this. The reason I think this is a bug is because, in certain circumstances, a revdep-rebuild on my system will try to re-emerge both gconf and gnome-vfs, but it orders gnome-vfs before gconf. The re-emerge of gnome-vfs then fails. More details about how I came across this are available in this forum post: http://forums.gentoo.org/viewtopic.php?t=163377&start=197 Reproducible: Always Steps to Reproduce: 1. 2. 3.