I'll plan update ImageMagick now - https://bugzilla.redhat.com/show_bug.cgi?id=579458
ABI change follow.
And according it I have some questions. New minor version of IM made around 1-2 times in week. What policy I should use to handle it? Have it worth update it in rawhide each time when new version arrived (I hope no)? For stable releases I though in action http://fedoraproject.org/wiki/Package_update_guidelines and shortly I should submit updates only for bugfixes.
Must I notify someone about coming update? How? Is it enough write here?
Am Sonntag, den 25.04.2010, 18:11 +0400 schrieb Pavel Alexeev (aka Pahan-Hubbitus):
I'll plan update ImageMagick now -
[snipped]
Must I notify someone about coming update? How? Is it enough write here?
I suggest to use repoquery --whatrequires ImageMagick and repoquery --disablerepo=* --enablerepo=rawhide --whatrequires ImageMagick and mail all the owners of the packages directly. You can use <packagename>-owner@fedoraproject.org instead of looking up the individual addresses.
Regards, Christoph
On Sun, Apr 25, 2010 at 7:13 PM, Kevin Kofler wrote:
Christoph Wickert wrote:
repoquery --disablerepo=* --enablerepo=rawhide --whatrequires ImageMagick
FYI, repoquery --repoid=rawhide --whatrequires ImageMagick does the trick too.
That does not detect packages that require ImageMagick-c++, ImageMagick-perl etc. The wildcard * seems to work. So it would be good to run a command to include the subpackages of ImageMagick, with the --alldeps flag, e.g.
$ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick* etc
Orcan
26.04.2010 05:04, Orcan Ogetbil пишет:
On Sun, Apr 25, 2010 at 7:13 PM, Kevin Kofler wrote:
Christoph Wickert wrote:
repoquery --disablerepo=* --enablerepo=rawhide --whatrequires ImageMagick
FYI, repoquery --repoid=rawhide --whatrequires ImageMagick does the trick too.
That does not detect packages that require ImageMagick-c++, ImageMagick-perl etc. The wildcard * seems to work. So it would be good to run a command to include the subpackages of ImageMagick, with the --alldeps flag, e.g.
$ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick* etc
Orcan
It produce big list of packages, thank you.
What about second part of my questions? How frequently I should (can) update package?
On Sun, May 2, 2010 at 7:20 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
26.04.2010 05:04, Orcan Ogetbil пишет:
On Sun, Apr 25, 2010 at 7:13 PM, Kevin Kofler wrote:
Christoph Wickert wrote:
repoquery --disablerepo=* --enablerepo=rawhide --whatrequires ImageMagick
FYI, repoquery --repoid=rawhide --whatrequires ImageMagick does the trick too.
That does not detect packages that require ImageMagick-c++, ImageMagick-perl etc. The wildcard * seems to work. So it would be good to run a command to include the subpackages of ImageMagick, with the --alldeps flag, e.g.
$ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick* etc
Orcan
It produce big list of packages, thank you.
What about second part of my questions? How frequently I should (can) update package?
There was a huge debate about the updating packages policy in the last months in this list. I don't think there is a unique answer to this question.
I would say, it is left to the decision of the maintainer. It all comes down how big the update is.
* Suppose there is a big API/ABI change: If you believe that you can deal with rebuilding all the dependent packages, and support them all in stable branches, go ahead and update. Otherwise update only in rawhide and let people know that they need to rebuild their packages, or rebuild them yourself. * Just a bugfix release, with no API/ABI breakage: In this case it should be safe to update.
I tried to answer the question as neutral as possible as I don't want to restart the bitchfest.
Orcan
03.05.2010 03:37, Orcan Ogetbil пишет:
On Sun, May 2, 2010 at 7:20 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
26.04.2010 05:04, Orcan Ogetbil пишет:
On Sun, Apr 25, 2010 at 7:13 PM, Kevin Kofler wrote:
Christoph Wickert wrote:
repoquery --disablerepo=* --enablerepo=rawhide --whatrequires ImageMagick
FYI, repoquery --repoid=rawhide --whatrequires ImageMagick does the trick too.
That does not detect packages that require ImageMagick-c++, ImageMagick-perl etc. The wildcard * seems to work. So it would be good to run a command to include the subpackages of ImageMagick, with the --alldeps flag, e.g.
$ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick* etc
Orcan
It produce big list of packages, thank you.
What about second part of my questions? How frequently I should (can) update package?
There was a huge debate about the updating packages policy in the last months in this list. I don't think there is a unique answer to this question.
I would say, it is left to the decision of the maintainer. It all comes down how big the update is.
- Suppose there is a big API/ABI change: If you believe that you can
deal with rebuilding all the dependent packages, and support them all in stable branches, go ahead and update. Otherwise update only in rawhide and let people know that they need to rebuild their packages, or rebuild them yourself.
- Just a bugfix release, with no API/ABI breakage: In this case it
should be safe to update.
I tried to answer the question as neutral as possible as I don't want to restart the bitchfest.
Orcan
Thank you, Orcan. And off course I do not want any holly-war. I just wonder about frequently of upstream releases (as I say before around one in week). Is it normal update it in rawhide each time?
About ABI breakage there separate problem in ImageMagick - http://www.mail-archive.com/debian-bugs-dist@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...
On Sun, May 16, 2010 at 11:14 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
I just wonder about frequently of upstream releases (as I say before around one in week). Is it normal update it in rawhide each time?
About ABI breakage there separate problem in ImageMagick - http://www.mail-archive.com/debian-bugs-dist@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...
Hi Pavel, It should be okay to update stuff in rawhide, but you probably need to give time to maintainers to rebuild their packages before branchings (for example, to F-14) or rebuild them yourself.
Is the upstream not bumping the soname when they change the ABI? That's not very nice. Is there no way to "educate" them?
You can use Debian's unresolved symbols detection script that is mentioned in the above link. I would say, rebuilding 30(?) packages every other week just for an ImageMagick update would be impractical, even if it is done in rawhide only. If you are not comfortable with detecting the ABI breakage, or if you can't dedicate enough time, I recommend to update every 2-3 months.
Let's hear what others will say.
Orcan
16.05.2010 19:35, Orcan Ogetbil пишет:
On Sun, May 16, 2010 at 11:14 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
I just wonder about frequently of upstream releases (as I say before around one in week). Is it normal update it in rawhide each time?
About ABI breakage there separate problem in ImageMagick - http://www.mail-archive.com/debian-bugs-dist@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...
Hi Pavel, It should be okay to update stuff in rawhide, but you probably need to give time to maintainers to rebuild their packages before branchings (for example, to F-14) or rebuild them yourself.
Is the upstream not bumping the soname when they change the ABI? That's not very nice. Is there no way to "educate" them?
You can use Debian's unresolved symbols detection script that is mentioned in the above link. I would say, rebuilding 30(?) packages every other week just for an ImageMagick update would be impractical, even if it is done in rawhide only. If you are not comfortable with detecting the ABI breakage, or if you can't dedicate enough time, I recommend to update every 2-3 months.
Let's hear what others will say.
Orcan
Thank you very much for the answers.
On 16 May 2010 21:05, Orcan Ogetbil wrote:
On Sun, May 16, 2010 at 11:14 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
I just wonder about frequently of upstream releases (as I say before around one in week). Is it normal update it in rawhide each time?
About ABI breakage there separate problem in ImageMagick - http://www.mail-archive.com/debian-bugs-dist@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...
[..]
mentioned in the above link. I would say, rebuilding 30(?) packages every other week just for an ImageMagick update would be impractical, even if it is done in rawhide only. If you are not comfortable with detecting the ABI breakage, or if you can't dedicate enough time, I recommend to update every 2-3 months.
+1, Keeping a careful look at changes they introduce with each release and whether it is really worth the hassle.
On 05/16/2010 02:53 PM, Rakesh Pandit wrote:
On 16 May 2010 21:05, Orcan Ogetbil wrote:
mentioned in the above link. I would say, rebuilding 30(?) packages every other week just for an ImageMagick update would be impractical,
Are you referring to ABI changes or just rebuilds.
For rebuilds, we should have a complete rebuild every night or every weekend - anything that needs rebuilding does and if it doesn't it doesn't. That way we have a consistent build tree always.
And oh yeh - we should do that build using rawhide too.
For ABI changes that are not backward compatible (is thats what happening here?) ... it depends how hard it is to script any changes to other packages.
g
2010/5/16 Pavel Alexeev (aka Pahan-Hubbitus) forum@hubbitus.com.ru
About ABI breakage there separate problem in ImageMagick - http://www.mail-archive.com/debian-bugs-dist@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. 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. http://koji.fedoraproject.org/koji/rpminfo?rpmID=1858222
Regards, Chen Lei
Hi,
On 05/17/2010 03:13 AM, Chen Lei wrote:
2010/5/16 Pavel Alexeev (aka Pahan-Hubbitus) <forum@hubbitus.com.ru mailto:forum@hubbitus.com.ru>
About ABI breakage there separate problem in ImageMagick - http://www.mail-archive.com/debian-bugs-dist@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: [hans@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
2010/5/22 Hans de Goede hdegoede@redhat.com
Hi,
On 05/17/2010 03:13 AM, Chen Lei wrote:
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:
- 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.
. This is actually my fault:) . ImageMagick strangely relies on those .la files to load modules. Containing .la files in packages will pull in libtool as dependency, can we filter it out?
Chen Lei
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)<forum@hubbitus.com.ru mailto:forum@hubbitus.com.ru>
About ABI breakage there separate problem in ImageMagick - http://www.mail-archive.com/debian-bugs-dist@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: [hans@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:
- 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.
On Sun, May 30, 2010 at 10:59 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
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. https://admin.fedoraproject.org/mailman/listinfo/devel
I wouldn't push that. I did the merge review for ImageMagick a long time ago and things may have changed since then though. From what I remember, the .la files that are not directly in %{_libdir} were needed by some plugins. If you remove those .la files, you kill the plugins.
Orcan
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 05/30/2010 11:59 PM +9:00:
22.05.2010 17:28, Hans de Goede пишет:
This is not necessarily good advice either:
- 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.
At least you have to check if removing libtool files in module directory won't raise this issue again: https://bugzilla.redhat.com/show_bug.cgi?id=185237
Regards, Mamoru
30.05.2010 19:22, Mamoru Tasaka пишет:
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 05/30/2010 11:59 PM +9:00:
22.05.2010 17:28, Hans de Goede пишет:
This is not necessarily good advice either:
- 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.
At least you have to check if removing libtool files in module directory won't raise this issue again: https://bugzilla.redhat.com/show_bug.cgi?id=185237
Awesome! $ convert -list format | wc -l 7 Mamoru, very thank you! I add comment in spec now with link to that bug to do not miss it in the future!
Regards, Mamoru
-
Chen Lei -
Christoph Wickert -
Genes MailLists -
Hans de Goede -
Kevin Kofler -
Mamoru Tasaka -
Orcan Ogetbil -
Pavel Alexeev -
Rakesh Pandit