On 10/06/2010 03:26 PM, Jason L Tibbitts III wrote:
>>>>>> "JM" == Jon Masters<jonathan@xxxxxxxxxxxxxx> writes:
>
> JM> In the past, I've written custom find-requires/find-provides
> JM> scripts. That's one option if you want to do all the heavy lifting
> JM> yourself, then you can disable the internal dependency generator in
> JM> RPM. That should be a last resort though - why exactly do you need
> JM> to do this? :)
>
> The problem is that if you disable the internal dependency generator,
> you lose the arch coloring bits which is exactly the reason why the
> available simple filter mechanism can't be used in this instance.
>
> As far as I know, we simply have no dependency filtering mechanism that
> works when you install binary executables or libraries in the regular
> search paths.
Thanks for the info. After looking closely it looks like not filtering
shouldn´t create any real problems other than putting some spurious provides
that are unlikely to get matched by anything else. But it would be great if
it could get fixed some day.
The issue in this case is the paraview{,-openmpi,-mpich2} package, which has a
lot application specific shared libraries in %{_libdir}/paraview. The "real"
binaries are also installed in there as well. So, for example:
# ldd /usr/lib64/paraview/paraview-real
linux-vdso.so.1 => (0x00007fffcc5c9000)
libpqApplicationComponents.so => not found
libpqComponents.so => not found
libQtPython.so => not found
libpqCore.so => not found
libQtTesting.so => not found
libpqWidgets.so => not found
libQtHelp.so.4 => /usr/lib64/libQtHelp.so.4 (0x0000003840200000)
libQtXml.so.4 => /usr/lib64/libQtXml.so.4 (0x0000003843c00000)
.... lots more
The "not found" libraries are in %{_libdir}/paraview and show up in the
Requires and Provides, even though they are only useful for paraview. But I
still need to capture the dependencies on things like libQtHelp.so.4 which
come from the system qt library.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion@xxxxxxxxxxxxx
Boulder, CO 80301 http://www.cora.nwra.com
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
