[91179] trunk/dports/sysutils/yum/Portfile

[Anders F Björklund]

Ryan Schmidt wrote:

>> Don't all the various versioned rpmxy ports also provide a librpm.dylib?  I think they do which means they should all conflict with one another (they don't seem to right now)
> 
> If that's so, what's the purpose of offering the separate ports at all?

The files already conflict, so there was no need to make the ports do too.

Actually the libraries doesn't conflict (different names), the headers and
the binaries do. And the supporting configuration and manpages, and such.

>> 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.

You can change the lib: dependency to a path: dependency, if you want to
disallow it using /usr/lib/librpm.so and /usr/local/lib/librpm.dylib...


Some earlier questions:

> Actually there is no librpm.dylib, its always librpm-X.Y.dylib.

There is just the symbolic link, which is used when developing/linking.

>> Again you are reacting to a non-existent fact:
>> 	There is no librpm.dylib being installed.
> 
> If no librpm.dylib is installed, the dependency on "lib:librpm:rpm" makes no sense.


As written now, the dependency is on the symlink and not on the library.


It _should_ probably be a depends_build on the symlink and a depends_run
on the actual library linked, but it's using depends_lib for both...

i.e. like a "BuildRequires: rpm-devel" and a "Requires: librpm*(*)"

Even better would be if yum could just require the "rpm" module,
for whichever version of python that happened to be in use...

But the paths of those are even worse than the ones for the libraries.

Maybe if one could split the python module out, into a "py-rpm".
But then it would still need one such, for each major rpm version ?

--anders