Bugzilla Bug 8222

Attached is quake2-0.14.1-ebuild.tar.bz2. This is the quake2 linux port done by 
relnev, centered at http://icculus.org/quake2/. It should probably go into 
app-games/quake2.

Created an attachment (id=4066) [details]
tarball of quake2-0.14.1.ebuild and other files

this tarball contains:

-Edited Makefile
quake2/files/Makefile

-Start scripts for the bin dir
quake2/files/sdlquake2.start
quake2/files/quake2.start
quake2/files/q2ded.start

-Readme for installing data and other bits
quake2/files/README-postinstall

-The ebuild
quake2/quake2-0.14.1.ebuild

What it does not contain:
The data paks. Those you have to buy :)

nice, ill take a look at it after the 1.4 freeze ;)

instead of doing:
tarball_version=`echo $P | sed -e 's/quake2-//'`
name=quake2-r${tarball_version}
S=${WORKDIR}/$name
SRC_URI="http://icculus.org/quake2/files/$name.tar.gz"

you can use the built in bash replacement:
MY_P="${P/-/-r}"
S="${WORKDIR}/${MY_P}"
SRC_URI="http://icculus.org/quake2/files/${MY_P}.tar.gz"

also, now we use virtual/x11 for X

instead of using syntax like this:
if (use sdl); then

try this:
if [ `use sdl` ] ; then

the reason for this is that () executes a new copy of the bash shell and if you 
were to use statements in there like 'die', it would only affect that sub 
shell ...
(die blah) would kill the subshell, not the main shell that is executing the 
ebuild

are you running Gentoo 1.4 ?
you commented out the aalib section saying it didnt work for you, but when i
uncommented it, it worked on my machine ...

No, I'm still using 1.2. Is there a way to test for the compiler version (other 
than the obvious gcc --version, of course)? Also, I've made the changes you  
suggested in my own tree, and I'm almost done with a 0.15 ebuild- i think I've  
figured out the qmax thing, so I'll attach a new tarball when i'm done. 

Created an attachment (id=4974) [details]
quake2-0.14.1.ebuild (rewritten some what)

here, check this for some suggestions ;)

*sigh*
It looks like in the time it was just sitting on my computer, someone else DID 
make an ebuild.  Heh.  Well, mine (#9927) appears redudant now.  I didn't 
think to look again before I submitted it (only, apparently, immediately 
after). Check it out for my approach.  Will look at yours.  ::)

*** Bug 9927 has been marked as a duplicate of this bug. ***

ah well i guess ill just add it and let users bitch about it ;)

http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-x86/app-games/quake2/quake2-0.14.1.ebuild?rev=1.1&content-type=text/vnd.viewcvs-markup

Created an attachment (id=5565) [details]
.14.1 and .15 ebuilds, plus a makefile change from what's currently in	portage

Here's the newer stuff- all that's left is the QMAX build that I'm still
kicking around. This contains:

quake2-0.14.1.ebuild
quake2-0.15.ebuild
files/Makefile

done 
and might i add, if only all games had linux ports this fscking good 
 
http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-x86/app-games/quake2/quake2-0.15.ebuild?rev=1.1&content-type=text/vnd.viewcvs-markup 

Hiya ::)

I am still using my personal Quake 2 ebuild (which turned-out to be redundant).  Well,
an evolved version anyway.  Here are some reasons why:

1.  There are multiple Quake 2 source-ports, and there will be more.  Refering to this
one as simply "quake2" implies that it is The Official Quake 2.  I suggest calling it 
"quake2-relnev"

2.  Mine stores it's data in a source-port-independent location, and in a
source-port-independent way.  It does so using by keeping it's data seperately, in
/usr/share/games/quake2-relnev and linking to the basic Quake 2 data in
/usr/share/games/quake2-data.  I finally just submitted my quake2-data ebuild, to pull
the data off of CD or out of a user-specified location.

3.  Style:  I'm a snob, and prefer my way to yours.  :;)

  I would say that the first two warrant changes, whether or not the third does is
less clear.  ::)

  I just submitted bug #11506 ( at http://bugs.gentoo.org/show_bug.cgi?id=11506), which
installs the Quake 2 data from CD or otherwise.  I think it would be good if this
ebuild was slightly modified to use it.  Try adding lines such as this to src_install():

# Now populate baseq2 with symlinks and source-port specific files
dosym /usr/share/games/quake2-data/baseq2/pak0.pak /usr/share/games/quake2-relnev/baseq2/pak0.pak
dosym /usr/share/games/quake2-data/baseq2/pak1.pak /usr/share/games/quake2-relnev/baseq2/pak1.pak
dosym /usr/share/games/quake2-data/baseq2/pak2.pak /usr/share/games/quake2-relnev/baseq2/pak2.pak
dosym /usr/share/games/quake2-data/baseq2/players /usr/share/games/quake2-relnev/baseq2/players
dosym /usr/share/games/quake2-data/baseq2/video /usr/share/games/quake2-relnev/baseq2/video

...
and the same for ctf, rogue, and xatrix sub-directories

  Are the gamei386.so files portable across source-ports (and redundant, rather than
conflicting)?  If so, one could just symlink baseq3 instead of the individual paks (any
additional ones will need to be individually sym-linked by hand - not a big deal, but it
would be nice if one didn't have to).
  Sorry, I was going to re-write the ebuild with most of my complaints fixed and attach
it, but it is late and I wanted to at least mention my new quake2-data ebuild.  I kept
getting lost trying to modify the quake2 ebuild to change the things I had mentioned,
and the result would have looked more like the one I already have than the one in
Portage.  If you want me to, I will attach mine after I
incorporate changes from yours.  I was not confident that all I USE flags would work in
all cases.  Which brings me to my last complaint  for this comment  ::)
  Why use a custom Makefile, when you can use sed to modify the existing one?  It is more
self-contained, using fewer Gentoo-specific downloads, and you don't have to replace the
file and try to figure-out what you cut last-time when a new version comes-out.

  Counter-comments welcome  ::)
- Daniel Mannarino

ill look at these suggestions when i have time 

Created an attachment (id=6427) [details]
quake2-relnev-0.15-r1.ebuild (A Slightly Different Approach)

Okay, here's my attempt to merge the best of our ebuilds.

- Daniel

Created an attachment (id=6428) [details]
files/sdlquake2-relnev.start

Here's the script to start the sdl binary

Created an attachment (id=6429) [details]
files/quake2-relnev.start

Here's the script to start the plain binary

Created an attachment (id=6430) [details]
files/q2ded.start

And here's the dedicated server script

from e-mail: look into QMAX support

Ok, did the QMAX stuff. I don't mean to ignore your changes, Daniel, but I'm
just going with 
what's currently in there. Some of your changes I agree with, some I don't.
Just in response to 
your points, though: 

1. Really, the only other port that could qualify for the "quake2" name without
suffix is 
quakeforge's, but it's not really any better than this (and, actually, I'd say
worse, just because of 
the mess they had to make to get it to use autoconf). There won't ever be an
"official" quake2, 
per se, because the official one won't compile on linux :) 

2. I did something much the same, except I made quake2-qmax depend on quake2,
and left the 
data in /usr/share/games/quake2, then symlinked it. 

3. eh :) To answer one of your lower questions, no, the game*.so isn't even
compatible across 
compiles, heh. It breaks savegames if you recompile. Also, your point about sed
vs a new 
Makefile is well taken, but I find sed code evil and ugly. More personal
preference :) 

Anyway, this one installs a QMAX-version of quake2. It's set up to be installed
in 
app-games/quake2-qmax. Data is symlinked from app-games/quake2, which this
depends on, so 
that's good. Start scripts installed as <script>-qmax. Also, i patched the
source to use 
$HOME/.quake2-qmax as the config dir, so it doesn't touch the normal quake2
config. None of 
the vid_ref drivers really appear to work except for sdlgl, but I left the X
one in case I was just 
unlucky. Running sdlquake2-qmax will get you sdlgl by default, since softsdl
doesn't seem to 
work either. Eh, YMMV. Test! 

Created an attachment (id=8872) [details]
app-games/quake2-qmax-0.15

See comment above.

   Hiya
   Actually, you know, I've been meaning (literally for weeks, yikes) to
visit this again to say "Hi: I don't really remember what most of my changes
did; it probably introduced new problems (even though it seems to work for me); yours seems to work fine anyway; just forget I posted :;)"
   There is only one change that I really feel strongly about, and that is
the name.  I think it should be quake2-relnev.  The seperate quake2-data
ebuild is perhaps a little much.  Requiring manual sym-linking is probably
not too much to ask of the user: It's too much space for me to have multiple
Quake 2 data sets though.
   Making a QuakeForge 2 ebuild is going to require more ambition than I
have at the moment (though the tarball is sitting amongst a pile of others
I had intended to make ebuilds for in my home directory). qfusion I
successfully compiled/ran, but it is somewhat confusing as to where it stands
(based on Quake 2 source, but adds in many Quake 3 features, and uses Quake 3
data - actually requires Quake 3!).  Anyway, I'm rambling now.  I withdraw
objections to this ebuild, except for the name.  ::)

-- Daniel Mannarino

Created an attachment (id=12953) [details]
Modified Makefile to the ${filesdir}

This Makefile uses the CFLAGS from make.conf

Created an attachment (id=12954) [details]
Makefile which uses CFLAGS from make.conf

Tested only on x86. RELEASE_CFLAGS could be merged into one linem because
portage takes care of CFLAGS.

ok, it is now called quake2-revnel and has been totally reworked 
 
try the sob out :) 
 
oh and lets open problems with this ebuild as new bugs, danke 
 
http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-x86/app-games/quake2-revnel/quake2-revnel-0.15.ebuild?rev=1.1&content-type=text/vnd.viewcvs-markup