On Mon, 2012-06-04 at 11:22 +0200, Nicolas Chauvet wrote:
> Hi,
>
>
> I was trying to check if packages on my system has defined a rpath (1)
> , I've made a little script:
>
> # for f in $(ls /usr/lib64/*.so.* ) ; do chrpath ${f} &>/dev/null;
> RETVAL=$?; if [ ! $RETVAL == 2 ] ; then chrpath ${f} ; rpm -qf ${f} ;
> echo "" ; fi; done
>
> This script reported around 70 rpath on my system related to nearly 20
> different components.
>
> For the record, rpmdev-setuptree adds a rpm macro for a local RPM
> packaging environment:
> %__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
> So that's prevent rpmbuild to build a package using rpath with success.
> This is not defined in the fedora buildsys by default. (nor autoqa ?...)
>
> Now I would like to know how to massively report a bug for each
> related component ? (at least those that define an rpath in /usr/lib64
> from a library in the same directory).
> Is there any experience doing such bugreport ?
>
> For the root cause of the rpath issue on lib64 system is related to a
> non-upstreamed patch (2) from libtool that prevents (most of the time)
> the detection of the lib64 sub-directory to be in the default search
> path of the system linker. Project generated from an upstream version
> of libtool are likely to generate such issue.
>
> Nicolas (kwizart)
>
>
>
> (1) http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
> (2) http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob_plain;f=libtool-2.2.10-rpath.patch;hb=master
I'd start with a mass mailing the maintainers of affected packages and
only after giving them some time to fix the problem I'd rerun the check
and file the bugs to the remaining unfixed packages.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
