On Wed, Dec 12, 2012 at 11:36 AM, Brian Long <briandl...@gmail.com> wrote:
> On Wed, Dec 12, 2012 at 9:05 AM, George Galt <george.g...@gmail.com>wrote: > >> Brian: >> >> As I noted above, there appears to be a mismatch between what RPM >> believes the package provides and what it requires. For the 304.51 driver, >> the -libs file "provides" libnvcuvid.so.1, and "requires" libnvcuvid.so.1. >> However, for the 310.19 driver, the -libs file provides "libnvcuvid.so.1" >> but requires "libnvcuvid()(64-bit). The list of what is "provided" by a >> package and "required" by a package is generated by RPM. It seems that >> somehow RPM inspects the 310-libs package and gets the list wrong, but got >> it right on the 304-libs package. >> >> I don't know if there is a way other than the macros to alter the >> "requires" list to properly state that the 310-libs package requires >> libnvcuvid.so.1, but that is where things are failing. I hope this helps. > > > Could you just use the following inside the .spec? > Autoreq: 0 > > This would make the RPM rely solely on the "Requires:" entries specified > in the .spec, but it wouldn't search for automatic requirements. > > Just an idea. > > /Brian/ > > _______________________________________________ > atrpms-devel mailing list > atrpms-devel@atrpms.net > http://lists.atrpms.net/mailman/listinfo/atrpms-devel > Brian: As I mentioned somewhere in this thread, I'm new to building rpms, so I'm not in a position to evaluate your proposal. However, assuming it does what you say, and the SPEC was populated with a reasonable list, it would seem to be a good option. George
_______________________________________________ atrpms-devel mailing list atrpms-devel@atrpms.net http://lists.atrpms.net/mailman/listinfo/atrpms-devel
