vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| This is an issue that I knew would bite, but which I just saw. LIB_DEPENDS implicitly recurses through RUN_DEPENDS and LIB_DEPENDS. So, when trying to update a package directly, the forward dependency check will find direct library dependencies, but not indirect ones. Thus, updating gettext will lead from libintl.so.1.1 to libintl.so.2.0, and direct dependencies will be happy, such as gtk+. Indirect dependencies won't. There are several ways to solve this. - with binary packages, a bit wasteful: always consider the transitive closure of forward dependencies for shared libraries, e.g., lock all packages that depend upon something that depend on libintl.so.1.1 to libintl.so.1.1, and refuse for it to vanish. - with ports, hard to do: stop recursing in LIB_DEPENDS_CHECK, so that people have to mention all library depends. - the one I'm favoring. Introduce a LIB_DEPENDS_EXTRA variable, which will hold only the library specs, and no packages specs at all. This variable should hold all libraries that the package will depend upon. Both lib-depends-check and package create will use this variable to discover and flatten LIB_DEPENDS_CHECKs... There is still the issue that, potentially, a given library may come from another package that just happens to match the same dependency path, but I don't think we need to worry about that right now. |