| Summary: | ebuild: games-puzzle/mures | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alexandru Toma <flash3001> |
| Component: | [OLD] Games | Assignee: | Gentoo Games <games> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| URL: | http://mures.sourceforge.net/ | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
mures-0.5.ebuild
mures-0.5-screenshot.patch mures-0.5-save.patch mures-0.5.ebuild mures-0.5.ebuild : inherit eutils, if [ `use -> if use mures-0.5.ebuild mures-0.5.ebuild mures-0.5.ebuild mures-0.5.ebuild |
||
|
Description
Alexandru Toma
2004-06-01 13:41:36 UTC
Created attachment 32489 [details]
mures-0.5.ebuild
Created attachment 32490 [details, diff]
mures-0.5-screenshot.patch
Created attachment 32491 [details, diff]
mures-0.5-save.patch
There's really not much point to this patch as the game doesn't have any "load
game" functionality even though it can save games (maybe it was planed for a
future version). However, since I didn't know how the program reacted when it
tried to save the game in a place where it couldn't because of permissions, I
just thought it might be better to change the save game location to the home
dirrectory.
Created attachment 32513 [details]
mures-0.5.ebuild
A few things: eutils needs to be inherit'd for epatch if [ `use... needs to become if use ... installs a bunch of .lua files but lua isn't mentioned in DEPEND? hmmm.... The hack has to be cleaned up before it goes into portage. >> eutils needs to be inherit'd for epatch I have always wondered about this. Epatch seems to work without inherit eutils for me... are you absolutely sure? And if so, why does it work without inherit eutils? >> if [ `use... needs to become >> if use ... quote from man 5 ebuild: "use <USE item> If USE item is in the USE variable, USE item will be echoed and the function will return 0. If USE item is not in the USE vari- able, the function will return 1. Example: if [ `use gnome` ] ; then guiconf="--enable-gui=gnome --with-x" elif [ `use gtk` ] ; then guiconf="--enable-gui=gtk --with-x" elif [ `use X` ] ; then guiconf="--enable-gui=athena --with-x" else # No gui version will be built guiconf="" fi" end quote Also shouldn't that be "If USE item is not in the USE vari- able, the function will return 0."?! >> installs a bunch of .lua files but lua isn't mentioned in DEPEND? hmmm.... The game package already provides lua. At least for me, it worked without lua installed. >> The hack has to be cleaned up before it goes into portage. Definately :) ... I just don't know how to do it Created attachment 32514 [details]
mures-0.5.ebuild : inherit eutils, if [ `use -> if use
Created attachment 41311 [details]
mures-0.5.ebuild
Finally got a chance to look at the program again and immediately managed to
solve the problem. That's what 4 months can do ;)
Created attachment 41312 [details]
mures-0.5.ebuild
On second thought... that sed belongs in src_unpack()
The opengl stuff doesn't look like it works to me. Does something automatically rebuild configure after you've modified configure.in? I don't know if it automatically rebuilds configure, but it worked for me. _How_ does it not work for you? Can you be a little more explicit? Anyway, I've reworked the ebuild a little bit. Hopefully it should solve your problems. If it doesn't work then please tell me _how_ it doesn't work. Created attachment 54582 [details]
mures-0.5.ebuild
Created attachment 55989 [details]
mures-0.5.ebuild
Updated header.
It's been almost a year already since this bug was fixed. Is there any interest of getting this ebuild in portage? Don't get me wrong, I'm not complaining, I just want to know if I should keep updating the ebuild or not. Also, I would like to know if there are any technical issues with the ebuild that I could possibly help with. I understand that you're all busy, but I think a minimum level of communication between developers and users is in order. You're already at the minimum level of communication. Do you think we need less? We can surely accomodate that one. ;] Do you really want us making comments just like this one in every single bug stating that while this bug has not gone away, it will one day be completed? How about I give you a time estimate? I think this bug will be resolved 13 days after SpanKY wins the United States presidency. Now that my own sarcasm has piqued my interest in this, I'm adding it to my personal TODO list. However, I am in an away status at the moment, due to buying a new house, so anything on my list has to wait a few weeks. If one of the other guys hasn't done it by then, I'll put this in portage. As for updating the ebuild, it is definitely a better idea than abandoning them. After all, if the ebuild stays updated, then when we do visit it, we can simply test/commit, rather than having to update it for the latest version ourselves. Many times bugs get passed over for easier ones, especially when time is limited. If you read the posts you will see that Mr Bones complained that the opengl stuff doesn't work for him without saying why or posting more information. Even after I tried fixing the problem he did not reply. This is the kind of stuff you for which you close bugs immediately if the users do it. Shouldn't developers set an example? This is what I was reffering to when I mentioned the lack of communication between developers and users. As far as your sarcastic comment is concerned, I think it is childish and totally uncalled for. I tried to formulate my post so as not to sound like I'm pestering or begging you, it was mainly to point out the lack of communication. I also tried to keep it as polite and respectful as possible. Maybe I failed to do that, however, this is no reason to post comments like the one you posted. I thought Gentoo had an etiquette policy ( http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2 ). This has really left a bad taste in my mouth. Wow... what can I say except that some of you guys really need to lighten up. Did you see the little ";]" at the end of that? Yeah, that means it is a joke. It means I was pulling your leg and trying to ease tension by being funny. If this has left a bas taste in your mouth, then I'm sorry, but you have to understand that we're all volunteers here, and we like to have fun. Pointing out our own policies as if we don't know them is rather insulting. I'm not really going to comment on that anymore, as there's no point. Anyway, I gave you your answer in the last post. I'll check it out as soon as I get more free time to work on Gentoo. We're a bunch of jokers on the games team. If this offends you in some way, please refrain from posting games requests, as I am sure we will continue to be the jovial personalities that you all either love ot loathe. ;] Do I feel embarased? Yes. I did see the ";]" but the square bracket (instead of the round one) fooled me. If I made any comments that insulted you please accept my appologies. It was not on purpose. I know all the Gentoo developers are volunteers. I don't know if I've made more than two or three comments regarding the fact that things were not getting fixed or not getting added to portage since I started using Gentoo a few years ago. I _always_ keep in mind the fact that you are volunteers. However, we, the users trying to contribute to Gentoo by filing bug reports or submitting ebuilds, are also volunteers. When you (the developers) post things like "this, or that doesn't work" I know it's because you're trying to help. But please also post how, what or why it doesn't work. Maybe even an error message. This also goes for the users, of course. Again, I would like to appologise, for the previous post. If it was insulting it was maybe because I was also offended by what I thought was a rude comment. This is no excuse, I know. Sorry! Added to CVS...
Just a couple quick notes.
- You can use doins -r to do recursive copies
- This may be my personal preference, but I prefer to install the binary/shell script into the actual game directory and use games_make_wrapper to do the install into /usr/games/bin
- Use ${dir} instead of ${DEST_DIR}... this is purely cosmetic, but it follows the same structure as most other games ebuilds
Also, I left the DEPEND section the same. My only question is whether or not the game actually *requires* those versions or not. If it could work wiht lower versions, it should either be specified that way, or it should be left without a version atom. I'm not saying you did anything wrong, as I didn't check myself (yeah, yeah, bad wolfie) and am pretty much just trying to be informative.
Thanks for the ebuild (and the patience!)
- You can use doins -r to do recursive copies
* Thanks! I'll remember that.
- This may be my personal preference, but I prefer to install the binary/shell script into the actual game directory and use games_make_wrapper to do the install into /usr/games/bin
* I thought, and please correct me if I'm wrong, that it was the Gentoo policy for games to always put the binary/script in /usr/games/bin and only use a wrapper script if there was no way to patch the binary/script to use the Gentoo paths.
- Use ${dir} instead of ${DEST_DIR}... this is purely cosmetic, but it follows the same structure as most other games ebuilds
* Heh... this was my way of writing game ebuilds back then. I don't think there were a lot of ebuilds that that used ${dir} back then, at least not that I'm aware of. Also, you mean ${dir} as in a local variable defined with 'local dir' right? What would be a proper solution for the current ebuild? I used ${DEST_DIR} in several functions (src_unpack as well as src_install). Should I define ${dir} for both of them, or just make ${dir} global?
- Also, I left the DEPEND section the same. My only question is whether or not the game actually *requires* those versions or not. If it could work wiht lower versions, it should either be specified that way, or it should be left without a version atom.
* I think the DEPEND section can be safely changed to just
DEPEND="media-libs/libsdl
media-libs/sdl-image
media-libs/sdl-net
media-libs/sdl-ttf
opengl? ( virtual/opengl )"
since older versions are no longer in portage anyway. Those were the versions I tested it with (which were stable at the time) so I thought it sensible to use those in the ebuild so as not to generate possible erroneous bug reports from users about mures not working with older versions of those libraries.
- Use ${dir} instead of ${DEST_DIR}... this is purely cosmetic, but it follows the same structure as most other games ebuilds
* Heh... this was my way of writing game ebuilds back then. I don't think there were a lot of ebuilds that that used ${dir} back then, at least not that I'm aware of. Also, you mean ${dir} as in a local variable defined with 'local dir' right? What would be a proper solution for the current ebuild? I used ${DEST_DIR} in several functions (src_unpack as well as src_install). Should I define ${dir} for both of them, or just make ${dir} global?
Don't bother answering that (I just saw the ebuild you comitted, it wasn't in portage yet when I posted the question above) and I see what you meant.
- This may be my personal preference, but I prefer to install the binary/shell script into the actual game directory and use games_make_wrapper to do the install into /usr/games/bin * I thought, and please correct me if I'm wrong, that it was the Gentoo policy for games to always put the binary/script in /usr/games/bin and only use a wrapper script if there was no way to patch the binary/script to use the Gentoo paths. There isn't really a policy, but you're right. It should go into /usr/games/bin. > There isn't really a policy, but you're right. It should go into /usr/games/bin.
Right. So aren't you going to change the ebuild so that it installs the binary in /usr/games/bin then? Like in the original ebuild?
Also, if you're going to do that you might as well trim version numbers from DEPEND since, as I've mentioned above, there are no older versions than those in portage anymore.
Also, there are six makefiles which `rm -f src/*/Makefile*` fails to delete. Those in maps/battle and maps/puzzle. |
