attached is a new ebuild for Shank 2, available from Humble Indie Bundle 7. Couple comments: 1. I couldn't find any license information, so I used all-rights-reserved 2. It includes some bundles libraries: libGLEW.so.1.5 because this version is no longer in portage, and three FMOD libraries because the version in portage doesn't include one of the necessary libraries. It looks like the version available in bug 453748 should work, but after installing that I could no longer play Bastion, another game that depends on FMOD. So, I'm sticking with the bundled version until that can be worked out. Reproducible: Always
Created attachment 342876 [details] games-action/shank2-7.ebuild One other comment I forgot to mention: aside from the license, I also can't find any version information. The only obvious version info is from the filename - update7. Obviously this doesn't translate to a version 7, but since I couldn't find anything more specific that's what I'm going with for now. If anyone knows what version the Linux port is based on, please share; I'll go ahead and update the ebuild accordingly.
- you probably want RESTRICT="bindist" as well - provide a "bundled-libs" useflag. We are not able to fix any bugs coming from new versions of any library, so IMO there should always be the option to use all bundled crap to ensure some kind of long-term compatibility, even though that might explode in fire too - ${PN^} <- that's a bash-4 feature and not allowed in ebuilds - keywords should be: KEYWORDS="-* ~amd64 ~x86" - double check that media-libs/libsdl does not need any useflag... that is very rare - the first part of einfo in pkg_postinst is obsolete - make the second part an elog - you can drop empty DEPEND variable - remove MY_UPDATE=7 and use $PV instead
(In reply to comment #2) > - ${PN^} <- that's a bash-4 feature and not allowed in ebuilds > - keywords should be: KEYWORDS="-* ~amd64 ~x86" > - the first part of einfo in pkg_postinst is obsolete > - make the second part an elog > - you can drop empty DEPEND variable fixed > - you probably want RESTRICT="bindist" as well how does that apply here? As I understand it, bindist is for preventing redistribution of binary packages you build yourself. In this case, there's nothing to build; there's *only* the prebuilt binary that will be fetch-restricted. > - double check that media-libs/libsdl does not need any useflag... that is very rare how exactly do I determine this? I know you're talking about the video/audio/joystick stuff, but if I do an ldd all I can see is that it uses libSDL-1.2.so.0. The only ways I know of to get more specific than that is: 1. Check documented dependencies (which is usually not documented in that level of detail), or 2. Take a trail-and-error approach to see what works/fails with various USE flag combinations (which is not very reliable) I'd love to learn a more thorough/accurate way of resolving these dependencies. Would appreciate any guidance you can provide here. > - provide a "bundled-libs" useflag. <SNIP> I'm perfectly fine with that. Just to confirm I'm thinking the same as you, though, I'm going to take this approach: * necessary bundled libs (glew and fmod) are always installed, regardless of bundled-libs * optional bundled libs (everything else) are only installed if USE=bundled-libs * also update dependencies based on USE=bundled-libs Does that work? Btw, searching through portage right now, I see nine packages using bundled-libs, and seven using system-libs. Far as I can tell, these do the exact same thing, just from an opposite perspective. Is there a reason both exist, or why one should be used over the other? I'd like to be consistent about this and use whichever is preferred going forward. > - remove MY_UPDATE=7 and use $PV instead Unless you're planning on adding this to portage right away, I'd rather hold off on this for now until we can get the actual version. As I explained in my previous comment, I'm only using 7 for the PV because I can't find something more accurate; I'd like to set PV to the real version of the game, and have the 7 be treated like a patch or something (eg., shank2-1.0_p7). Hmm... Either way that'll require changing things and getting rid of MY_UPDATE, so I'll go ahead and change it now as your requested. I'd still suggest treating this as a temporary version until (if) we can get the actual version number, though.
(In reply to comment #3) > > - you probably want RESTRICT="bindist" as well > > how does that apply here? As I understand it, bindist is for preventing > redistribution of binary packages you build yourself. In this case, there's > nothing to build; there's *only* the prebuilt binary that will be > fetch-restricted. It's about building the binpackage, not building the source. You must not create binpkgs from an "all-rights-reserved" (as in: no rights) package. > > > - double check that media-libs/libsdl does not need any useflag... that is very rare > > how exactly do I determine this? I know you're talking about the > video/audio/joystick stuff, but if I do an ldd all I can see is that it uses > libSDL-1.2.so.0. The only ways I know of to get more specific than that is: > > 1. Check documented dependencies (which is usually not documented in that > level of detail), or > > 2. Take a trail-and-error approach to see what works/fails with various USE > flag combinations (which is not very reliable) > > I'd love to learn a more thorough/accurate way of resolving these > dependencies. Would appreciate any guidance you can provide here. simple answer: test it, rebuild libsdl with all useflags disabled (does not take long anyway) otherwise: read the source > > > - provide a "bundled-libs" useflag. <SNIP> > > I'm perfectly fine with that. Just to confirm I'm thinking the same as you, > though, I'm going to take this approach: > > * necessary bundled libs (glew and fmod) are always installed, regardless of > bundled-libs > * optional bundled libs (everything else) are only installed if > USE=bundled-libs > * also update dependencies based on USE=bundled-libs > > Does that work? > > Btw, searching through portage right now, I see nine packages using > bundled-libs, and seven using system-libs. Far as I can tell, these do the > exact same thing, just from an opposite perspective. Is there a reason both > exist, or why one should be used over the other? I'd like to be consistent > about this and use whichever is preferred going forward. I couldn't really decide which ones to use. I rather add "system-libs" if I want the default to be "bundled libs" (also see googleearth), e.g. when system libs break the shit out of the package. Although you could do "+bundled-libs" I think the other useflag name indicates "uh-oh". > > > - remove MY_UPDATE=7 and use $PV instead > > Unless you're planning on adding this to portage right away, I'd rather hold > off on this for now until we can get the actual version. As I explained in > my previous comment, I'm only using 7 for the PV because I can't find > something more accurate; I'd like to set PV to the real version of the game, > and have the 7 be treated like a patch or something (eg., shank2-1.0_p7). > > Hmm... Either way that'll require changing things and getting rid of > MY_UPDATE, so I'll go ahead and change it now as your requested. I'd still > suggest treating this as a temporary version until (if) we can get the > actual version number, though. use $PV, you already named your ebuild shank2-7.ebuild so what you are using in SRC_URI does not make any difference to the situation. MY_UPDATE is just a useless variable in this case
although I might be wrong on the bindist thing, I'll ask license team
Created attachment 342952 [details] games-action/shank2-7.ebuild ok, this version should cover all your points. I still get QA warnings, though, and I'm not sure why: * QA Notice: Pre-stripped files found: * /opt/shank2/bin/lib64/libfmodex64.so * /opt/shank2/bin/lib64/libfmodex64-4.42.07.so * /opt/shank2/bin/lib64/libfmodevent64.so * /opt/shank2/bin/lib64/libGLEW.so.1.5 scanelf: rpath_security_checks(): Security problem with relative DT_RPATH './lib64:$ORIGIN/lib64' in /tmp/portage/games-action/shank2-7/image/opt/shank2/bin/shank2-bin64 scanelf: rpath_security_checks(): Security problem with relative DT_RPATH './lib64:$ORIGIN/lib64' in /tmp/portage/games-action/shank2-7/image/opt/shank2/bin/shank2-bin64 Should the included QA variables not suppress that? I've verified that the paths and filenames set in those variables are correct, so I really don't know why it's still printing that warning.
<ulm> hasufell: for all-rights-reserved, you need both mirror and bindist restriction in our case we use fetch instead of mirror ofc... regarding your QA_var issue, maybe try QA_PRESTRIPPED="${GAMEDIR:1}/bin/lib32/* ${GAMEDIR:1}/bin/lib64/*" Maybe it does not like the wildcard in between. It's ok to include directories in that variable that might not even exist, that is not fatal.
Created attachment 343044 [details] games-action/shank2-7.ebuild (In reply to comment #7) > regarding your QA_var issue, maybe try > QA_PRESTRIPPED="${GAMEDIR:1}/bin/lib32/* > ${GAMEDIR:1}/bin/lib64/*" Huh... that works. Attached version includes the change. Also, thanks for the clarification regarding bindist here. I'll need to start adding that to my other HIB ebuilds as I update them.
Created attachment 343046 [details] games-action/shank2-7.ebuild sorry, forgot to remove some debugging commands
since I don't own that game, I cannot import/support it however you can send a pull request @ sunrise: https://github.com/hasufell/sunrise or just join #gentoo-sunrise and ask for review and get commit access to the beta repository
