Bug 194374
Summary: | Review Request: kdegames: K Desktop Environment - Games | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Rex Dieter <rdieter> |
Component: | Package Review | Assignee: | Chitlesh GOORAH <chitlesh> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | dennis, gauret, hugo, than, wart |
Target Milestone: | --- | Flags: | rdieter:
fedora-review+
|
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-04-06 12:42:05 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 200236 |
Description
Rex Dieter
2006-06-07 16:39:58 UTC
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 |