3:20 p.m.
Since this just came up and I'm working on an issue.
I need to filter from Provides/Requires everything in a file generated at the
end of the %install step. Is this possible with the tools listed in
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering?
It's not obvious to me if it is. I can't use %filter_provides_in because I do
need to capture some but not all requires from those items.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
3:27 p.m.
On 10/06/2010 02:20 PM, Orion Poplawski wrote:
Since this just came up and I'm working on an issue.
I need to filter from Provides/Requires everything in a file generated at the
end of the %install step. Is this possible with the tools listed in
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering?
It's not obvious to me if it is. I can't use %filter_provides_in because I do
need to capture some but not all requires from those items.
Also, I'm afraid that my package installs binaries in /usr/bin, so it looks
like I couldn't use the above filters anyways. What to do?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
4:21 p.m.
On Wed, 2010-10-06 at 14:27 -0600, Orion Poplawski wrote:
On 10/06/2010 02:20 PM, Orion Poplawski wrote:
> Since this just came up and I'm working on an issue.
>
> I need to filter from Provides/Requires everything in a file generated at the
> end of the %install step. Is this possible with the tools listed in
> https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering?
> It's not obvious to me if it is. I can't use %filter_provides_in because I
do
> need to capture some but not all requires from those items.
>
Also, I'm afraid that my package installs binaries in /usr/bin, so it looks
like I couldn't use the above filters anyways. What to do?
In the past, I've written custom find-requires/find-provides scripts.
That's one option if you want to do all the heavy lifting yourself, then
you can disable the internal dependency generator in RPM. That should be
a last resort though - why exactly do you need to do this? :)
Jon.
4:26 p.m.
>>>> "JM" == Jon Masters
<jonathan(a)jonmasters.org> 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.
- J<
4:46 p.m.
On 10/06/2010 03:26 PM, Jason L Tibbitts III wrote:
>>>>> "JM" == Jon
Masters<jonathan(a)jonmasters.org> 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(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
5:58 p.m.
On Wed, Oct 06, 2010 at 02:27:07PM -0600, Orion Poplawski wrote:
On 10/06/2010 02:20 PM, Orion Poplawski wrote:
> Since this just came up and I'm working on an issue.
>
> I need to filter from Provides/Requires everything in a file generated at the
> end of the %install step. Is this possible with the tools listed in
> https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering?
> It's not obvious to me if it is. I can't use %filter_provides_in because I
do
> need to capture some but not all requires from those items.
>
If you want to remove every provide that could be generated by a file use
%filter_provide_in.to filter out that provide. If you want to filter
a specific provide/set of provides then use %filter_from_provides.
Also, I'm afraid that my package installs binaries in /usr/bin, so it looks
like I couldn't use the above filters anyways. What to do?
Yep, that's the case. If the extraneous provides are causing no known bugs
to occur, just leave them for now. At some point, someone needs to look at
adapting rpm to be able to handle these things itself but I don't think
anyone is working on that at the moment.
-Toshio
4949
days inactive
4949
days old
packaging@lists.fedoraproject.org
5 comments
4 participants
participants (4)
-
Jason L Tibbitts III -
Jon Masters -
Orion Poplawski -
Toshio Kuratomi