22.05.2010 17:28, Hans de Goede пишет: > Hi, > > On 05/17/2010 03:13 AM, Chen Lei wrote: > >> >> 2010/5/16 Pavel Alexeev (aka Pahan-Hubbitus)<fo...@hubbitus.com.ru >> <mailto:fo...@hubbitus.com.ru>> >> >> >> About ABI breakage there separate problem in ImageMagick - >> >> http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg736218.html >> So, upstream is not carefully there and I never can't guarantee what >> there no ABI breakage in any update... >> >> P.S. It seams it does not hit list, i post mail again. It is reason >> such big delay... >> >> -- >> >> Normally, if the update is a pure bugfix release, it's safe to update >> and don't need a rebuild, and you should update them on rawhide as well >> as stable branches to fix bugs >> If API/ABI is changed, only the following packages need a rebuild. >> Packages depends on ImageMagick itself actually don't need a rebuild >> even the API is changed. >> > Wrong, the main ImageMagick provides libs too, on F-13 the full list is: > [h...@localhost anaconda]$ repoquery -q --whatrequires > 'libMagickCore.so.2()(64bit)' 'libMagickWand.so.2()(64bit)' > 'libMagick++.so.2()(64bit)' > ruby-RMagick-0:2.13.1-1.fc13.1.x86_64 > ImageMagick-djvu-0:6.5.8.10-6.fc13.x86_64 > vips-tools-0:7.20.7-1.fc13.x86_64 > rss-glx-0:0.9.1.p-2.fc13.x86_64 > q-magick-0:7.11-6.fc12.x86_64 > nip2-0:7.20.7-3.fc13.x86_64 > ale-0:0.9.0.3-2.fc12.x86_64 > zbar-0:0.10-2.fc13.x86_64 > psiconv-0:0.9.8-5.fc12.x86_64 > xastir-1:1.9.6-3.fc13.x86_64 > ImageMagick-c++-0:6.5.8.10-6.fc13.x86_64 > ImageMagick-perl-0:6.5.8.10-6.fc13.x86_64 > vips-0:7.20.7-1.fc13.x86_64 > autotrace-0:0.31.1-23.fc12.x86_64 > inkscape-view-0:0.47-6.fc13.x86_64 > k3d-0:0.8.0.1-1.fc13.x86_64 > drawtiming-0:0.7.1-1.fc13.x86_64 > dx-libs-0:4.4.4-15.fc13.x86_64 > dx-0:4.4.4-15.fc13.x86_64 > pfstools-0:1.8.1-1.fc13.x86_64 > gdl-python-0:0.9-0.10.rc4.fc13.x86_64 > oxine-0:0.7.1-6.fc13.x86_64 > xine-lib-extras-0:1.1.18.1-1.fc13.x86_64 > transcode-0:1.1.5-4.fc13.x86_64 > ImageMagick-devel-0:6.5.8.10-6.fc13.x86_64 > imageinfo-0:0.05-10.fc12.x86_64 > vips-python-0:7.20.7-1.fc13.x86_64 > calibre-0:0.6.42-1.fc13.x86_64 > pfstools-imgmagick-0:1.8.1-1.fc13.x86_64 > php-pecl-imagick-0:2.2.2-4.fc12.x86_64 > inkscape-0:0.47-6.fc13.x86_64 > php-magickwand-0:1.0.8-4.fc12.x86_64 > k3d-0:0.7.11.0-6.fc13.x86_64 > gdl-0:0.9-0.10.rc4.fc13.x86_64 > zbar-0:0.10-2.fc13.x86_64 > transcode-0:1.1.5-4.fc13.x86_64 > ImageMagick-devel-0:6.5.8.10-6.fc13.x86_64 > vips-python-0:7.20.7-1.fc13.x86_64 > calibre-0:0.6.42-1.fc13.x86_64 > ImageMagick-c++-0:6.5.8.10-6.fc13.x86_64 > vips-tools-0:7.20.7-1.fc13.x86_64 > rss-glx-0:0.9.1.p-2.fc13.x86_64 > vips-0:7.20.7-1.fc13.x86_64 > php-magickwand-0:1.0.8-4.fc12.x86_64 > oxine-0:0.7.1-6.fc13.x86_64 > nip2-0:7.20.7-3.fc13.x86_64 > xine-lib-extras-0:1.1.18.1-1.fc13.x86_64 > php-pecl-imagick-0:2.2.2-4.fc12.x86_64 > inkscape-0:0.47-6.fc13.x86_64 > k3d-0:0.8.0.1-1.fc13.x86_64 > ImageMagick-c++-devel-0:6.5.8.10-6.fc13.x86_64 > drawtiming-0:0.7.1-1.fc13.x86_64 > pfstools-imgmagick-0:1.8.1-1.fc13.x86_64 > gdl-python-0:0.9-0.10.rc4.fc13.x86_64 > pfstools-0:1.8.1-1.fc13.x86_64 > k3d-0:0.7.11.0-6.fc13.x86_64 > inkscape-view-0:0.47-6.fc13.x86_64 > gdl-0:0.9-0.10.rc4.fc13.x86_64 > > > >> repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick-c++ >> ImageMagick-c++-0:6.6.0.2-8.fc14.i686 >> ImageMagick-c++-0:6.6.0.2-8.fc14.x86_64 >> inkscape-0:0.48-0.2.20100505bzr.fc14.x86_64 >> ImageMagick-c++-devel-0:6.6.0.2-8.fc14.x86_64 >> gdl-0:0.9-0.12.rc4.fc14.x86_64 >> pfstools-imgmagick-0:1.8.1-1.fc14.x86_64 >> drawtiming-0:0.7.1-1.1.fc14.x86_64 >> pfstools-0:1.8.1-1.fc14.x86_64 >> ImageMagick-c++-devel-0:6.6.0.2-8.fc14.i686 >> k3d-0:0.8.0.1-1.fc14.x86_64 >> gdl-python-0:0.9-0.12.rc4.fc14.x86_64 >> inkscape-view-0:0.48-0.2.20100505bzr.fc14.x86_64 >> BTW, some subpackages contain .la files, you should remove them in %install. >> e.g. >> > This is not necessarily good advice either: > 1) As these la files are for plugins which are located outside of %{_libdir}, > they do no harm > 2) In the past there have been cases with plugins where the libraries plugins > loading mechanism relies on the .la files being present, that might very well > be the case here. > > Regards, > > Hans > Very interesting. Actually spec file contain string to delete in root build directory: rm $RPM_BUILD_ROOT%{_libdir}/*.la What can happened bad if I do: find $RPM_BUILD_ROOT -type f -name "*.la" -exec rm -f {} \; as Chen Lei suggested before?
Actually I done that, but update is not pushed yet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
