Created attachment 330556 [details] file.tar.gz fixed by building without link.
Marking as invalid since I'm pretty sure you have some non-tree snapshot or git version of sfml2 installed and this requires <sfml-2 that's in the tree.
First of all i only am on gentoo and gamerlay . Second of all if that is the case there should be ebuild check. sfml2 doesnt seem to exist in portage. "emerge: Maybe you meant any of these: media-libs/csfml, dev-ruby/sfl, dev-python/pysfml?" Dont make assumptions.
(In reply to comment #2) > First of all i only am on gentoo and gamerlay . > Second of all if that is the case there should be ebuild check. > > sfml2 doesnt seem to exist in portage. > "emerge: Maybe you meant any of these: media-libs/csfml, dev-ruby/sfl, > dev-python/pysfml?" > > Dont make assumptions. So what version of media-libs/libsfml do you have installed? I'm guessing libsfml-2.0_rc20120731 from gamerlay... and my assumption will be correct. :P
# emerge libsfml These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] media-libs/libsndfile-1.0.25 USE="alsa sqlite -minimal -static-libs" 0 kB [ebuild N ] media-libs/libsfml-2.0_rc20120731::gamerlay USE="-debug" 0 kB 1. ebuild doesnt use link ? libsfml<2 when it should 2. if 2.0 is not compatible it should block it.
> 1. ebuild doesnt use link ? libsfml<2 when it should Yes it depends on libsfml properly for link support. > 2. if 2.0 is not compatible it should block it. No it shouldn't because 2.0 isn't in the main tree yet, overlays aren't supported. Closing again as invalid because this is obviously due to libsfml-2 problems and libsfml-2 isn't in the tree yet.
fine, cant gentoo games join efforts with gamerlay? much cleaner and easier this way.
(In reply to comment #6) > fine, cant gentoo games join efforts with gamerlay? much cleaner and easier > this way. 1) Gentoo Games team almost not related to gamerlay. 2) as gamerlay maintainer, all I can suggest is to mask >libsfml-1.6 either in portage tree's package mask or gamerlay one. And my suggestion is tree one, as it already contains some atoms from overlays (mariadb, for example). And, to be honest, if I imagine myself in place of gamerlay user, I think, I won't be happy on any in-overlay masking because of packages, not related to gamerlay, that are incompatible with modern versions of library, which gamerlay contains (and which some games depends). Let's discuss on that? :)
@mva, i have plans to add libsfml snapshot from gamerlay to main tree, see bug #442604. So, you are some point right - proper blockers or atom masking are needed.
Obviously proper blocking or masks are coming, but not before libsfml-2* gets added to the official tree.
(In reply to comment #7) > 1) Gentoo Games team almost not related to gamerlay. > 2) as gamerlay maintainer, all I can suggest is to mask >libsfml-1.6 either > in portage tree's package mask or gamerlay one. > And my suggestion is tree one, as it already contains some atoms from > overlays (mariadb, for example). Well i am suggesting moving the gentoo game team to gamerlay and make gamerlay an official addon to the portage tree, cleaner and efficient, now we have double efforts. Also it seems more logical because i think very little people actually use the gentoo games/related in portage tree, or am i wrong? > And, to be honest, if I imagine myself in place of gamerlay user, I think, I > won't be happy on any in-overlay masking because of packages, not related to > gamerlay, that are incompatible with modern versions of library, which > gamerlay contains (and which some games depends). > > Let's discuss on that? :) Well what you could do also is duplicate the vbam ebuild in your tree and link ? libsfml <2. But that again is double efforts.
(In reply to comment #10) > Well i am suggesting moving the gentoo game team to gamerlay and make > gamerlay an official addon to the portage tree, cleaner and efficient, now > we have double efforts. Also it seems more logical because i think very > little people actually use the gentoo games/related in portage tree, or am i > wrong? If anything, more contributors should aim to become devs to move games they like and want to maintain into the tree or find proxy-maintainers who are interested in helping them. Making an overlay as an official addon does not make things "cleaner and more efficient," quite the opposite as now an overlay has to be tracked and kept in sync with the tree.
What i do is move the vbam ebuild to gamerlay? Now we have duplicated efforts that are not compatible or do you mean move gamerlay to the main tree? While not everyone uses the games section of the portage tree you might see it as unnecesary syncing, file searching etc. If you mean contributing to the gamerlay i have no idea how. If you mean more maintainers for the main overlay i will still have to learn how these ebuilds works and i have otehr things to do.
I'd still vote for INVALID. If a package in the official tree depends on a specific version of a library that is in the tree, then you can actually fix the problem. If it should not depend on a version that is in an overlay, then you should use package.mask locally to fix the problem since you are combining the two trees. There isn't anything the overlay maintainer can do, and we can't do sweeping changes like marrying the two trees, or setting "defensive" negative dependencies in the official tree are insane (we'd never finish setting obscure deps like that).
Latest vbam snapshot in the tree builds against libsfml-2, older version limited to <libsfml-2.
