games.eclass has a few policies on how to use it. games.eclass is not inherited last here, games variables such as install destinations are not respected, games_pkg_preinst is ignored which can be used in conjunction with GAMES_STATEDIR (the ebuild currently uses /var/lib/games) and prepgamesdirs is missing. I suggest to go for review in #gentoo-games.
The whole /var/lig/games highscore setup for gnome-games is broken to be honest...
inheriting the eclass last does not guarantee its functions will be called by ebuild per PMS iirc. We will review the ebuild to add any phase function that might be missing currently.
(In reply to comment #2) > inheriting the eclass last does not guarantee its functions will be called > by ebuild per PMS iirc. I am fully aware of that. inheriting it last is just a precaution afais in case other inherited eclasses change their behavior and start to overwrite undefined phases via exports like pkg_setup or pkg_preinst that's _currently_ not the case here anyway since almost all phases are defined, however it can happen on version bump and such but you gnome guys could argue from the same perspective I guess... the most important things are respected games variables for binaries/libs and games-data stuff and "prepgamesdirs" call for the permissions
This needs to be reviewed before starting to add all ebuilds for splitted gnome-games... not sure if we could have a gnome-games.eclass handling this need of games/gnome eclasses coexistence :|
(In reply to comment #4) > This needs to be reviewed before starting to add all ebuilds for splitted > gnome-games... not sure if we could have a gnome-games.eclass handling this > need of games/gnome eclasses coexistence :| Phases that would need to be used: - pkg_setup -> from games.eclass - src_configure -> we need settings from egamesconf... but would also be nice to pass some options from gnome2_src_configure... not sure what to do :| I would probably have a gnome-games_src_configure that would run gnome2_src_configure + prefix settings copied from egamesconf - src_compile -> from gnome2.eclass - pkg_{pre,post}inst -> from both eclasses Regarding highscores file... I have no idea about what to do :| In OpenSuSE and Fedora I cannot see any change related with highscores files
For now, this one is sent to upstream: https://bugzilla.gnome.org/show_bug.cgi?id=699482 But I still don't think gtk-doc and glib schemas should be installed on a different prefix :/
Created attachment 347146 [details] gnome-games.eclass Last eclass attempt
Reported this one because locales and /var/ are installed in wrong directories :S, if anyone has any idea about what is failing, please speak!
https://bugzilla.gnome.org/show_bug.cgi?id=699482
Created attachment 348058 [details] five-or-more-3.8.1.ebuild ebuild to test
Maybe intltool is the problem: https://bugs.launchpad.net/intltool/+bug/1030541
(In reply to comment #11) > Maybe intltool is the problem: > https://bugs.launchpad.net/intltool/+bug/1030541 We have various options: - Patch our intltool package and regenerate Makefile.in.in files (probably via eclass) - Keep our intltool as upstream (broken) and fix offending line in Makefile.in.in via eclass. Anyway, if upstream don't care, all generated tarballs will keep bogus if we don't regenerate files always with our patched intltool Any thoughts?
CCing intltool maintainers then per previous comment
scoredir='${localstatedir}/games' in configure.ac is the cause of /var/games/games... probably we will need to not set --localstatedir to GAMES_STATEDIR
+*intltool-0.50.2-r1 (26 May 2013) + + 26 May 2013; Pacho Ramos <pacho@gentoo.org> + +files/intltool-0.50.2-absolute-paths.patch, + +files/intltool-0.50.2-localedir-fix.patch, +intltool-0.50.2-r1.ebuild: + Use plain localedir to install mo files to rather than trying to guess one + (#432848#c11), fix handling absolute paths in single file key output + (#470040). +
(In reply to Pacho Ramos from comment #12) > Anyway, if upstream don't care, all generated tarballs will keep bogus if we > don't regenerate files always with our patched intltool > > Any thoughts? We can now DEPEND on fixed version, the problem is that, strictly, all current tarballs are bogus because were generated with broken upstream version. How should we fix them? intltoolize --copy --automake --force works but, where should we call it? On each broken ebuild (all)? at gnome-games.eclass? gnome2.eclass? (in that case, how can we easily add a check for calling it only when wrong Makefile.in.in is detected?)
(In reply to Pacho Ramos from comment #16) > (In reply to Pacho Ramos from comment #12) > > Anyway, if upstream don't care, all generated tarballs will keep bogus if we > > don't regenerate files always with our patched intltool > > > > Any thoughts? > > We can now DEPEND on fixed version, the problem is that, strictly, all > current tarballs are bogus because were generated with broken upstream > version. How should we fix them? > intltoolize --copy --automake --force > > works but, where should we call it? On each broken ebuild (all)? at > gnome-games.eclass? gnome2.eclass? (in that case, how can we easily add a > check for calling it only when wrong Makefile.in.in is detected?) I would go for calling "intltoolize --copy --automake --force" always if "has_version dev-util/intltool" (to not add a DEPEND on intltool for all packages using gnome2.eclass) and if "${S}/po/Makefile.in.in" exists (otherwise, intltoolize is not needed and would fail). The advantage of running it always is that we "unbundle" Makefile.in.in file and are sure we use a file that we can easily control and fix. In this case, for example, we could simply stabilize fixed intltool version and add a blockers for older versions in DEPEND in gnome2.eclass
this is solved in 3.8
