Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: prboom - GPL doom game engine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185211 ------- Additional Comments From wart@xxxxxxxxxx 2006-03-13 03:03 EST ------- (In reply to comment #2) [...] > MUST-FIX > ======== > * Building gives a number of "integer <-> pointer of different size cast" > warnings these are _BAD_ on x86_64. I'll attach a patch fixing these. > One of these is a real bu, the others were ok. Thanks for catching this. It would be nice if there were a flag for gcc that would treat these "integer <-> pointer" warnings as errors, esp. on x86_64. > * %{_datadir}/prboom is not owned by the package > * why the %dir %{_datadir}/games/doom ? %{_datadir}/games/doom was supposed to be %{_datadir}/prboom. My bad. I've uploaded a new .spec with this fix. > About provide / req doom-game/-engine and Desktop files > ======================================================= > I've been thinking about this and initially I came up with the following: [...] > But this is /becomes a mess so I suggest instead: > -doom-engines provide dataname-engine for all datasets they support I'm not too keen on this because it means that every time a new iwad becomes available, the game engine package must be updated to signal that it can run it. The game engine package should not have to know about all of the possible dataname packages that it can run. > -doom-engines require enginename-data > -doom-data provide enginename-data for all engines they are known to work > with > -doom-data requires dataname-engine > -doom-data packages include the .desktop file and icons, the .desktop > file invokes "dataname" wich is a wrappercript provided by the engine > with the correct cmdline arguments to use the relevant wad. If it is possible> that there are multiple providers of dataname-engine then the alternatives > system will be used. I'm starting to think that using the alternatives system for game engines might be a little bit of overkill and introduce some unneeded complexity. If the game data was designed to work with a specific game engine, then the .desktop file should reflect that. If the game data can work with an alternate game engine, then that's great, but the user will have to do so from the command line. > This way (desktop-file in data package) if people install multiple versions of > the data (free-doom, heretic-shareware, doom-shareware) they get menu entries > for each. > -datafiles packages are named as the game and will show up in comps for easy > user selection (the reqs will drag in an engine). so the free-doom data > package will be called just free-doom, doom-shareware-package will be called > doom19-shareware, etc. +1 > I hope this makes sense and you think its a good idea :) It seems that all of this complexity is being added (and I admit that I started this messy discussion) only to support some level of indirection in the .desktop file. There are really only two simple requirements that I feel we must satisfy: 1) Each iwad has a usable .desktop entry so it can be run from the menu 2) Additional game engines can be installed to run the games If we don't try to mix these requirements (don't allow alternate game engines in the .desktop files) then it becomes much simpler and can be satisfied by a subset of your suggestion. Each game data package Requires: <enginname>, even if it is known to work with others. That game engine is hardcoded in the .desktop file and will be used when the game is launched from the menu. This ensures that users can 'yum install <gamedata>' and end up with the data, game engine, and a usable .desktop icon. Game data Provides: <enginename>-data for each engine that it is known to work with. Each game engine Requires: <enginename>-data so that when the engine is installed, it will pull in the data that can be played with the game. However, if the game data package Requires: a different enginename, then you might end up with a situation where "yum install engine2" results in the installation of engine2, game-data1, and engine1. It's a little odd this way, but it does ensure that both 'yum install enginename' and 'yum install dataname' still end up with working .desktop icons. Alternately, we can try to relax the "game engine requires game data" packaging requirement for game engines like prboom that are designed to work with multiple game data packages. There are really two classes of game engines. The first class of game engine is very self-contained, such as 'tong'. In this class of game engine, the game data is just 'skin', such as images and sound. The purpose of splitting the game data from the game engine in this case is to minimize the download size of package updates, not to provide alternate skins for the game. While alternate skins could be made available, it is unlikely to occur. Such game engines should require game data in order to be played. The second class of game engine are more 'game interpreters' like prboom, for which the game data packages provide a new game experience with new game logic. For example, 'freedoom' is more than a cosmetic change from the shareware doom game. Such engines should not have to require game data files, since the data files contain a large portion of the game logic. In this case, the game data is more than just skin, and it is expected that alternate game data packages will be available. They should only require that such data files exist and are available through the packaging system. I apologize if this sounds like rambling. I'll try to clarify anything if I've muddied it up too much. :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
