With the bugzilla outage, I'll copy and paste the other comments here:

------- Additional Comments From hugo.br  2006-06-12 11:14 EST 
-------

> # TODO: decide a good location for a world-writable 
--enable-highscore-dir=DIR

Maybe /var/games? Some distros are already using it.

BTW, I'm doing some experiences with this package regarding the "subpackage" 
approach we discussed in IRC other day (nickname Eitch). I'll follow this bug 
to let you know about something.

------- Additional Comments From rdieter.edu  2006-06-12 11:17 EST 
-------

Hugo, if you're willing to maintain kdegames, I'm all for the "subpackage"
approach... (:

------- Additional Comments From hugo.br  2006-06-12 11:55 EST 
-------

Hi Rex! I don't know if I can maintain it (yet) but I'm doing this for 
research first. I'll try to make a clean spec with the subpackage approach and 
present people with it. Then we'll see if it's worthy to maintain using one of 
the methods :)

I think that with these "big packages", it will be good to have one or more 
co-maintainers too, even not using the subpackages approach. As I'm in KDE 
SIG, count on me to help you on this, like testing, reviewing and such :)

------- Additional Comments From rdieter.edu  2006-06-12 12:00 EST 
-------

I certainly agree with the "co-maintainer" and/or "(kde)team maintainership"
approach...

About the highscore dir, we could use --enable-setgid and give the executables 
a setgid and ownership to root.games. This way, users can write in the score 
files under /var/games (which can be specified with the 
--enable-highscore-dir=/var/games).

When the --enable-highscore-dir is used, the make install creates some .score 
files (ie kbounce.scores) and stores it in the directory configured 
(ie /var/games). These files needs to be owned by user root, group games, and 
permissions with 0664. This way the games executables that are setgid to games 
group can access and change them.

This is the way used in many currently games in FE. Examples that I'm seeing 
here right now: powermanga and nethack-vultures.

If you decide to do use setgid, then you will need to look at each setgid
executable and make sure that it drops setgid privileges immediately after
opening the high score file, which should be the first thing done in main(). 
This could be a tedious task and require quite a bit of patching for the 30+
games in this package, unless upstream has already been careful to do this.

For purposes of this review (and to keep things simple for the near-future), I
won't consider enabling the highscore/setgid bits.

OK "won't consider" might be too strong.  How about this: I intend not to enable
to the highscore/setgid bits, unless strong arguments are made to convince me
otherwise.  There.  (:

Rex: if supported, global highscores would be a good feature to multi-user 
system games. Other packages uses it, why not this one? It's not that 
complicated ;) just a few more lines in the spec and here we go.

Wart: I think upstream already cared about this issue. See this message from 
2003:

http://lists.kde.org/?l=kde-games-devel&m=105271154603114&w=2

I have looked on some code in khighscore.cpp and it looks like it's still 
implemented in recent versions. The code checks if the --enable-highscore-dir 
is used and then use the setgid feature, dropping immediately after.

Hi guys, I have created the experimental specfile for the sub-package concept:

Spec URL: http://www.devin.com.br/eitch/fextras/kdegames.spec
SRPM URL: http://www.devin.com.br/eitch/fextras/SRPMS/kdegames-3.5.3-3.src.rpm

I made the specfile as clean and organized as possible. It creates 36 
packages: one for common game files, one for devel files, one for card decks 
(used by lskat and kpat), one as a metapackage that requires all others and 
one for each game.

Hope you all like it. It is indeed more difficult to maintain, but not that 
much. I think we get some good advantages for the users. And I know this 
because I've asked to 10+ Linux users (beginners and experienced) and they 
*all* said that this approach is better.

Note: Since I don't have the 3.5.3 ready to install here, I have commented out 
the version requirements and using generic ones. In the spec you can note the 
"FIXME" warnings, these should be removed if you have these recent versions 
installed in the building machine.

Rex: I'm thinking in helping co-maintain KDE packages or trying to create a 
maintainer group for these KDE packages, based on the SIG. I really look 
forward for KDE improvement in Fedora Core :)

Sorry, I made a mistake. The correct URLs for the files are:

Spec URL: http://www.devin.com.br/eitch/fextras/SPECS/kdegames.spec
SRPM URL: http://www.devin.com.br/eitch/fextras/SRPMS/kdegames-3.5.3-3.src.rpm

The splitting looks promising... certainly worth considerring.  In the meantime...

Spec URL: http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/kdegames.spec
SRPM URL:
http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/kdegames-3.5.3-3.src.rpm

%changelog
* Mon Jun 19 2006 Rex Dieter <rexdieter[AT]users.sf.net> 6:3.5.3-3
- move %%_libdir/libkdeinit_*.so bits to main pkg

I see no shortcoming to the splitting, except maybe that if the default install
brings the meta-package "kdegames", and I want to remove kdegames-kmines later,
yum will tell me that it needs to remove kdegames-kmines and kdegames. This
could scare the user.
Well, kdegames is maybe not the best example here, but I know I was kind of
scared when I tried to remove a component of GNOME and yum told me it needed to
remove "gnome-desktop" with it.

Apart from that, it clearly has advantages, but we need to make really sure that
the packages are truly independant and work when the others are not installed.

(In reply to comment #10)
> I see no shortcoming to the splitting, except maybe that if the default
> install brings the meta-package "kdegames", and I want to remove
> kdegames-kmines later, yum will tell me that it needs to remove
> kdegames-kmines and kdegames. This could scare the user.
>
> Well, kdegames is maybe not the best example here, but I know I was kind of
> scared when I tried to remove a component of GNOME and yum told me it needed
> to remove "gnome-desktop" with it.

Do you know some resolution for this? Personally I don't think this is a big 
issue, but I think you can be right. I thought about it and don't get any good 
solution...

BTW I think koffice uses the same approach for now. Maybe Oo.org too. Many 
other distributions uses that way too. If the user knows that there exists 
packages, he/she should know that the base package is only a meta-package. 
This can be described in the Description field too.

> Apart from that, it clearly has advantages, but we need to make really sure
> that the packages are truly independant and work when the others are not
> installed.

I already took care of this, they work just fine. I tested every single game 
here, but another person doing this to confirm could be very helpful. I 
completely agree with "we need to make really sure" on packages. We have to 
provide high-quality packages to our users ;) And on this point, IMO, Fedora 
Extras is rocking. Keep it up!

Thanks for the feedback.

> %changelog
> * Mon Jun 19 2006 Rex Dieter <rexdieter[AT]users.sf.net> 6:3.5.3-3
> - move %%_libdir/libkdeinit_*.so bits to main pkg

Why an %exclude on devel package if the files are already defined under the 
main pkg?

%{_libdir}/lib*.so
%exclude %{_libdir}/libkdeinit_*.so

Means, I want (in -devel) all the lib*.so files *except* for the libkdeinit_.so
ones.

%{_libdir}/lib*.so
%exclude %{_libdir}/libkdeinit_*.so

Means, I want (in -devel) all the lib*.so files *except* for the libkdeinit_.so
ones.  Else, we'd get them included twice (ie, in both pkgs)

FYI, this has a good chance of making FE/fc6.

If by "good chance", I really meant very little chance, then I was about right.
 (:  Let's play it safe and stick with fc7 target.

I'll review this:

however :
1. I think the src.rpm I have to review is this one
http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/kdegames-3.5.5-1.src.rpm

2. why is this bug blocked by
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200236 ?

> 1. 1. I think the src.rpm I have to review is this one: kdegames-3.5.5-1.src.rpm

yup.

> 2. why is this bug blocked by kdeaddons, bug #200236

kdeaddons includes:
BuildRequires: kdegames-devel

MUST Items:

- MUST: The package is named according to the Package Naming Guidelines.
- MUST: The spec file name matches the base package %{name}
- MUST: The package meets the Packaging Guidelines.
- MUST: The package is licensed (GPL) with an open-source compatible license and
meet other legal requirements as defined in the legal section of Packaging
Guidelines.
- MUST: The License field in the package spec file matches the actual license.
- MUST: the source package includes the text of the license(s) in its own file,
then that file, containing the text of the license(s) for the package is
included in %doc.
- MUST: The spec file must be written in American English.
- MUST: The sources used to build the package must matches the upstream source,
as provided in the spec URL.
- MUST: The package successfully compiles and builds into binary rpms on at
least i386.
- MUST: All build dependencies is listed in BuildRequires.
- MUST: The spec file handles locales properly.
- MUST: If the package does not contain shared library files located in the
dynamic linker's default paths
- MUST: the package is not designed to be relocatable
- MUST: the package owns all directories that it creates.
- MUST: the package does not contain any duplicate files in the %files listing.
- MUST: Permissions on files are set properly.
- MUST: The package has a %clean section, which contains rm -rf %{buildroot} (or
$RPM_BUILD_ROOT).
- MUST: The package consistently uses macros, as described in the macros section
of Packaging Guidelines.
- MUST: The package contains code, or permissable content. This is described in
detail in the code vs. content section of Packaging Guidelines.
- MUST: There are no Large documentation files
- MUST: %doc does not affect the runtime of the application. To summarize: If it
is in %doc, the program must run properly if it is not present.
- MUST: The package does not contain library files with a suffix 
- MUST: Package containing GUI applications includes a %{name}.desktop file, and
that file must be properly installed with desktop-file-install in the %install
section.
- MUST: Package does not own files or directories already owned by other packages. 

SHOULD Items:

 - SHOULD: The source package does include license text(s) as COPYING
 - SHOULD: mock builds succcessfully in i386.
 - SHOULD: The reviewer tested that the package functions as described. A
package should not segfault instead of running, for example.
 - SHOULD:  scriptlets are sane. 
 - SHOULD: No subpackages present.

The following should be fixed before uploading to the build systeme, however I
won't block it for that because I know you will update it before doing so.

APPROUVED
 
#001: rpmlint issues
[chitlesh[0] ~]$ rpmlint
/var/lib/mock/fedora-development-i386-core/result/kdegames-3.5.5-1.fc7.src.rpm
W: kdegames macro-in-%changelog _bindir
W: kdegames mixed-use-of-spaces-and-tabs (spaces: line 81, tab: line 6)
W: kdegames patch-not-applied Patch1: kdegames-3.1.1-konquest.patch

at the same time, you can clean #Patch0: kde-libtool.patch as well

#002  X-Fedora .desktop category is not required anymore
  --add-category="X-Fedora" --vendor="" \

Now I guess you can work with the kdeaddons package.

i have already merged the changes and comitted in CVS. Please take a look at 
new package kdegames-3_5_6-2_fc7 in rawhide. Thanks

Does this mean that this bug can be closed now ?

no closing until package is merged into external cvs. (:

approved per comment #19, closing->rawhide per comment #21