Bugzilla Bug 52723

From The Linux Game Tome:
"A clone of Sega's Chu Chu Rocket

Mures is a cross-platform clone of Sega's "Chu Chu Rocket," a multi-player puzzle game. Players place arrows on a board in an attempt to guide the mice into their rockets and away from opponents' rockets. A great party game."


There is still a big issue with this ebuild, but there was nothing more I could do so I'll just post it here in hope that someone will fix it.

The problem lies with the flags passed on to the compiler. The program can be built with or without OpenGL support. If you want OpenGL support built in, you have to add -DHAVE_GL and -lGL to the CFLAGS, and if you don't want it then you don't have to add these flags. So far so good.

The problem arrises from the fact that, if you have OpenGL installed, the configure script autodetects this and passes these flags to the compiler. However, there may be persons that, even though they have OpenGL installed, may not want to build OpenGL support into the game.

So far I have been unable to nicely resolve this issue ... read "I lack the knowledge" (see the ebuild for the hack I have implemented). This should _definately_ be fixed _before_ the ebuild is added to portage.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Created an attachment (id=32489) [details]
mures-0.5.ebuild

Created an attachment (id=32490) [details]
mures-0.5-screenshot.patch

Created an attachment (id=32491) [details]
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 an attachment (id=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 an attachment (id=32514) [details]
mures-0.5.ebuild : inherit eutils, if [ `use -> if use

Created an attachment (id=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 an attachment (id=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 an attachment (id=54582) [details]
mures-0.5.ebuild

Created an attachment (id=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.