>>> and a path-based depends_lib like before is appropriate >> >> A path:-based depends_lib would be ok. a lib:-based depends_lib is not ok >> because that would allow a non-MacPorts librpm installed in a system >> directory to satisfy the dependency, and we don't want that. >> > > Again you are reacting to a non-existent fact: > There is no librpm.dylib being installed.
The various flavors that I quickly checked before sending the first e-mail all installed unversioned symlinks: [buster] ecronin% cd `port work rpm52`/destroot/opt/local/lib [buster] ecronin% ls librpm* librpm-5.2.dylib* librpmconstant-5.2.dylib* librpmio-5.2.dylib* librpm.a librpmconstant.a librpmio.a librpm.dylib@ librpmconstant.dylib@ librpmio.dylib@ librpm.la* librpmconstant.la* librpmio.la* librpmbuild-5.2.dylib* librpmdb-5.2.dylib* librpmmisc-5.2.dylib* librpmbuild.a librpmdb.a librpmmisc.a librpmbuild.dylib@ librpmdb.dylib@ librpmmisc.dylib@ librpmbuild.la* librpmdb.la* librpmmisc.la* One interesting thing we could be doing for the ports that we do have buildbot packaging now is generating a manifest of the files each installs and checking for filesystem conflicts where the ports don't declare themselves conflicting. It would be handy to have manifests for other reasons too (a while ago someone requested a debian like "ports x, y, z provide foo" instead of "command not found: foo" which manifests would be a starting point for developing) Thanks, Eric _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
