Bug 194374 - Review Request: kdegames: K Desktop Environment - Games
Review Request: kdegames: K Desktop Environment - Games
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chitlesh GOORAH
Fedora Package Reviews List
:
Depends On:
Blocks: 200236
  Show dependency treegraph
 
Reported: 2006-06-07 12:39 EDT by Rex Dieter
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-06 08:42:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rdieter: fedora‑review+


Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2006-06-07 12:39:58 EDT
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.testing/kdegames-3.5.3-2.src.rpm
Description:
Games and gaming libraries for the K Desktop Environment.
Included with this package are: kenolaba, kasteroids, kblackbox, kmahjongg,
kmines, konquest, kpat, kpoker, kreversi, ksame, kshisen, ksokoban, ksmiletris,
ksnake, ksirtet, katomic, kjumpingcube, ktuberling.

%changelog
* Wed Jun 07 2006 Rex Dieter <rexdieter[AT]users.sf.net> 6:3.5.3-2
- cleanup for Extras
- update %%description
- %%doc: COPYING, app docs (README, TODO, etc...)
- follow icon spec
- BR: desktop-file-utils
- --disable-setgid

* Fri Jun 02 2006 Than Ngo <than@redhat.com> 6:3.5.3-1
- update to 3.5.3
Comment 1 Hugo Cisneiros 2006-06-14 11:22:51 EDT
With the bugzilla outage, I'll copy and paste the other comments here:

------- Additional Comments From hugo@devin.com.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@math.unl.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@devin.com.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@math.unl.edu  2006-06-12 12:00 EST 
-------

I certainly agree with the "co-maintainer" and/or "(kde)team maintainership"
approach...
Comment 2 Hugo Cisneiros 2006-06-14 11:32:06 EDT
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.
Comment 3 Wart 2006-06-14 12:17:28 EDT
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.
Comment 4 Rex Dieter 2006-06-14 12:21:04 EDT
For purposes of this review (and to keep things simple for the near-future), I
won't consider enabling the highscore/setgid bits.
Comment 5 Rex Dieter 2006-06-14 12:29:54 EDT
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.  (:
Comment 6 Hugo Cisneiros 2006-06-14 13:07:06 EDT
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.
Comment 7 Hugo Cisneiros 2006-06-14 14:12:29 EDT
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 :)
Comment 8 Hugo Cisneiros 2006-06-14 14:14:41 EDT
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
Comment 9 Rex Dieter 2006-06-19 11:18:54 EDT
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


Comment 10 Aurelien Bompard 2006-06-19 16:18:02 EDT
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.
Comment 11 Hugo Cisneiros 2006-06-19 22:08:05 EDT
(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.
Comment 12 Hugo Cisneiros 2006-06-20 13:07:04 EDT
> %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?
Comment 13 Rex Dieter 2006-06-20 13:31:43 EDT
%{_libdir}/lib*.so
%exclude %{_libdir}/libkdeinit_*.so

Means, I want (in -devel) all the lib*.so files *except* for the libkdeinit_.so
ones.
Comment 14 Rex Dieter 2006-06-20 13:32:30 EDT
%{_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)
Comment 15 Rex Dieter 2006-07-26 10:32:26 EDT
FYI, this has a good chance of making FE/fc6.
Comment 16 Rex Dieter 2006-07-26 11:22:38 EDT
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.
Comment 17 Chitlesh GOORAH 2006-11-06 16:16:16 EST
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 ?
Comment 18 Rex Dieter 2006-11-06 16:24:31 EST
> 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
Comment 19 Chitlesh GOORAH 2006-11-06 17:24:43 EST
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="" \
Comment 20 Chitlesh GOORAH 2006-11-06 17:30:42 EST
Now I guess you can work with the kdeaddons package.
Comment 21 Ngo Than 2007-03-06 10:01:24 EST
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
Comment 22 Chitlesh GOORAH 2007-03-09 10:56:14 EST
Does this mean that this bug can be closed now ?
Comment 23 Rex Dieter 2007-03-09 11:11:43 EST
no closing until package is merged into external cvs. (:
Comment 24 Rex Dieter 2007-04-06 08:42:05 EDT
approved per comment #19, closing->rawhide per comment #21

Note You need to log in before you can comment on or make changes to this bug.