Bugzilla Bug 115079

Hi, just to tell that openrpg 1.6.3 is out and that the last ebuild available
is
1.6.1.

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

Created an attachment (id=74614) [details]
the ebuild

should work great, basically a renamed 1.6.1

Created an attachment (id=74615) [details]
the patch file... you'll need this too

this is the patch file used the old one as a template

Created an attachment (id=74617) [details]
the ebuild(working)

erm... so it was a little harder then that... but it works now

(From update of attachment 74617 [details])
builds but doesen't work

Version 1.6.3 seems to discover the path of the files dynamically.

With the current ebuild it crash as it will be looking at the file relatively
to the discovered root. The options, to me, are:

1) drop the package or
2) use a wrapper and leave the tree as it was "badly" designed or
3) fix every single place where it is referring to other files.

I won't do the 3rd :)

(In reply to comment #5)
> Version 1.6.3 seems to discover the path of the files dynamically.
> [...]
> 2) use a wrapper and leave the tree as it was "badly" designed or
> 3) fix every single place where it is referring to other files.

Could you expound on these a bit?  If you could explain what needs to be done,
perhaps someone else (e.g., myself) could do the grunt work.

> Could you expound on these a bit?  If you could explain what needs to be done,
> perhaps someone else (e.g., myself) could do the grunt work.

In the new openRPG version, the developer(s) seems to have "automatically"
detected where all the files are located, I guess taking the current path of a
python file, and then derived where all the other files are, just using this
path as a reference. This works only if we assure that the files are deployed
in the same way they are in the tar.gz . Gentoo, according to the
http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml
use to deploy files following its own rules.

So the work to be done is to replace any path, in openRPG, to point to the
correct location.

But the better would be that the developers do this, as we have, otherwise, to
reapply different patches to any new release of software.
Hope to be clear enough :/

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

openrpg-1.7.1 requires python 2.5 and wxpython 2.8. python 2.5 is not yet
unmasked (set a depend on bug 148333?), and wxpython 2.8 is not in the tree
(new bug needed?).

this is the last thing in the tree depending on wxpython-2.4.  we need a
decision made - update or remove.

The new version needs wxpython-2.8, so it should definitely not be removed but
updated. 

In the long run it is good!

I am working on a brand new ebuild for OpenRPG. The devs for OpenRPG have added
features that break the old ebuild's design. The current ebuild should be
removed from portage, as it is completely useless. The only way it *could* be
used, is if the user connected to a server running OpenRPG 1.6.1, of which
there are none listed on the metaserver.

I am still deciding exactly how to structure the ebuild, but I imagine in the
future OpenRPG will be installed in to /opt/openrpg1, and there will be a
shell-starter script in /usr/games/bin/ that cd's in to /opt/openrpg1 then
executes start.py. In other words, rather than using a gentoo-normalized
structure and editing every single openrpg path, why not preserve openrpg's way
of doing it and install to /opt/ (which is normally reserved for binary
installations, but this could be thought of as a "binary" in the sense that
nothing in it should be altered).

Created an attachment (id=119495) [details]
openrpg-1.7.1.ebuild

Working but security-flawed ebuild.

Like all previous versions of OpenRPG, this ebuild changes the
group-write-permissions to ON for the directory /usr/share/games/openrpg1. This
allows anyone in the "games" group to write and execute arbitrary code that is
shared amongst all users in the "games" group. I believe there is no solution
short of rewriting all of the pathing code in OpenRPG. The ebuild contains a
good 15-second pause to get this point across.

Created an attachment (id=119496) [details]
openrpg-client wrapper executable

A required file used in the installation of openrpg-1.7.1.

Created an attachment (id=119497) [details]
openrpg-server wrapper executable

A wrapper script for start-server.py

The provided ebuild and two wrapper executables (which both go in the files/
package directory) create a functioning OpenRPG-1.7.1 ebuild.

It is a complete rewrite of the old ebuild, and is probably NOT compatible with
it. You should --unmerge the previous OpenRPG's. I'm not sure what DEPENDS to
set to ensure this (-<games-rpg/openrpg-1.7.1 perhaps?).

This is my second ebuild ever (the first being a wxPython-2.8 ebuild provided
earlier today in bug #178727), so please look it over closely.

Could someone from the Gentoo Games herd please add bug 178727 as a depends for
this bug?

Happy gaming!

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

Ok, OpenRPG 1.8.0 is out, and uses wxpython 2.8.10.  Currently, this seems to
be in Last Rites because it "needs updated to use a newer wxpython than 2.6". 
I feel that updating the ebuild would be a far better solution to that problem
than simply removing OpenRPG from the tree.

--Arek75