Description of problem: Some programms need the "old" SFML-1.6 libraries. So make a new SFML-2.0 package instead of overwriting the existing one (an example is vbam-gtk). Steps to Reproduce: 1. yum upgrade (to SFML-2.0) 2. yum install vbam-gtk (rawhide must be enabled) 3. see an error
*** Bug 979802 has been marked as a duplicate of this bug. ***
SFML-2.0 is parrallel-installable with 1.6 now. Hans was working on compat-SFML16. Hans, would you be able to provide an update on this?
Hi, (In reply to Julian Sikorski from comment #2) > SFML-2.0 is parrallel-installable with 1.6 now. Hans was working on > compat-SFML16. Hans, would you be able to provide an update on this? Yes, long story short: I got side tracked with other stuff. But I've just picked up the track again and completed my compat-SFML16 package, see bug 983922 for the review request, please review. Once compat-SFML16 has been reviewed I'll build it for rawhide and F-19, while also upgrading the F-19 SFML packages to SFML-2.0 (merging it with the fedpkg master branch). Then I'll push both SFML-2.0 and compat-SFML16 as F-19 updates in one update. So if I can get a review of compat-SFML16 (easy, just a pkg rename of the existing F-19 package), we can have this resolved pretty quickly. Regards, Hans
compat-SFML16-1.6-1.fc19,SFML-2.0-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/compat-SFML16-1.6-1.fc19,SFML-2.0-2.fc19
Package compat-SFML16-1.6-1.fc19, SFML-2.0-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing compat-SFML16-1.6-1.fc19 SFML-2.0-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-13257/compat-SFML16-1.6-1.fc19,SFML-2.0-2.fc19 then log in and leave karma (feedback).
compat-SFML16-1.6-1.fc19, SFML-2.0-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
I found a problem in the acutal FindSFML.cmake, if you have both installed. When you do this: find_package(SFML 2 COMPONENTS system REQUIRED) it will throw out this: SFML found but version too low (requested: 2, found: 1.x) You will have a 50% chance of finding your correct version, otherwise it will break with an error. The cmake file tries to find the SFML/Config.hpp, which does exist twice, one for the old 1.6 and a new one for 2.0. Depending on which file will be found first, you will have the correct version or not. You could provide a switch for the version, but that will lead to a nasty workaround, but I don't see any other solution now. Maybe you can make up your mind.
(In reply to Marcel Hellwig from comment #7) > I found a problem in the acutal FindSFML.cmake, if you have both installed. > When you do this: > find_package(SFML 2 COMPONENTS system REQUIRED) > it will throw out this: > SFML found but version too low (requested: 2, found: 1.x) Well then don't do that. SFML-2.0 comes with pc files as shipped upstream, and cmake is perfectly capable of using pkg-config, and when available that is preferred over find_package, exactly because find_package does this blind groping around until it found something which may or may not work. I've no intention of supporting building against SFML for projects which don't use pkf-config, so please fix the buildfiles for whatever you're trying to build to use pkg-config. > You will have a 50% chance of finding your correct version, otherwise it > will break with an error. > The cmake file tries to find the SFML/Config.hpp, Yes, which is the wrong thing todo find_package is broken by design, so better not use it, esp. not when there is a sane alternative in the form of using pkg-config through pkg_search_module / pkg_search_modules, see /usr/share/cmake/Modules/FindPkgConfig.cmake . > but I don't see any other solution now. Use pkg-config is the solution.