2009/2/17 Michael Schwendt <mschwendt(a)gmail.com>:
On Sun, 15 Feb 2009 13:12:30 +0100, Thorsten wrote:
> On 14.02.2009 16:18, Julian Sikorski wrote:
> > this is for F10/testing. For some reason it did not get multilib'd
properly.
>
> Reason found, workaround applied, repo pushed, discussing real fix with
> mschwendt currently
Disabling the internal dep generator here breaks rpmbuild's automatic
SONAME deps for -devel pkgs.
The spec file enables a modified find-requires script that filters out
libnvidia-tls.so.1
libGLcore.so.1
but what happens additionally is that the -devel pkg ends up with no
SONAME dependencies at all because the script doesn't create any deps
for the -devel package. The x86_64 build is affected, too.
Re-enabling the internal dep generator, the result is this:
$ rpm -qpR xorg-x11-drv-nvidia-devel-180.29-1.fc10.i386.rpm | grep so
libGL.so.1
libXvMCNVIDIA_dynamic.so.1
libcuda.so.1
libvdpau.so.1
And with that, the multilib resolving would work _without_ an
explicit arch-specific dependency on the -libs package.
[...]
A cheap work-around would be to add explicit SONAME dependencies
in the -devel package [getting the '()(64bit)' for 64-bit arch right]
and adding a guard somewhere in %install that exits the build as soon
as the shared lib soname symlinks don't match the explicit deps
anymore.
It would be unaccurate according that:
- We have different serie for one given library as nvidia,
nvidia-173xx nvidia-71xx etc.
- Because the previous version of the package will remains in the
updates repository, it ends that for a given serie, the version
release) needs to be the same.
So it would be better IMO that:
Instead to add a requires on a library, let's make the -devel
subpackage to requires
%{name}-libs-%{_target_cpu} = %{version}-%{release} (which the -libs
already provides and it is how the main requires the libs already).
Does that will fit the needs of the multilib push script ?
Nicolas (kwizart)