Hi, On 24.02.2014 16:49, Andreas Tille wrote: > Hi Paul, > > On Mon, Feb 24, 2014 at 04:10:08PM +0800, Paul Wise wrote: >>> aptitude search '~sgames' -F %p >>> >>> I think such a file would be easy to maintain and could be >>> autogenerated. As you mentioned below there might be a better solution. >> >> I've been maintaining a machine with 'all' games installed for a few >> years now and I think the procedure you mention has a few issues and >> is not fully automatable in practice. >> >> Not all of the games are co-installable, some of them are variants of >> each other compiled for different toolkits and some of them conflict >> with one another. > > ... which fits Enricos statement (to which I perfectly agree) that > a well designed task is something else than doing proper DebTagging. The current main task file is really a raw version and only a demonstration how you can quickly obtain a list of all binary games packages in main and display them as a task. Of course you need a more fine grained approach for the final product. An "all-games-in-main" metapackage should later depend on the already existing separate blends tasks for games and include some filters / queries to remove unwanted packages. From my point of view DebTags is just a pool of information, the database, from which you can easily construct queries such as "All action games AND NOT data packages AND NOT server packages" However I'm now more and more inclined to drop the DebTags idea, given the fact that only three people want to attend to the DebTags party anyway, and to use that weekend to add the missing games to their corresponding tasks myself, remove conflicting/unwanted packages by hand and be done with it. Then let's create the metapackages and let those who are unhappy with them file bug reports and fix remaining issues in revision -2 -3 and so on until everyone is happy. I probably cared too much for other use cases. >> Some games are only installable on some architectures because their >> engine doesn't build on some architectures (fenix for eg). > > The new (not yet released) blends-dev package is able to deal with > different architectures. It creates architecture dependant > metapackages. (If I only had enough time to push a bit on this front > ...) I agree, the blends framework is the correct place to solve this issue. >> Some things in section games are data packages, game servers, game >> level editors or other game related things but are not actually games >> and shouldn't be in a games-all task. > > See above about the difference between tasks and DebTags. It depends on your preferences. Some games require servers, sometimes they are optional. Again if every games package was tagged correctly, such use cases could easily be implemented and tasks could be generated with a few simple commands. >> There may be some games that aren't in section games but are games. I >> haven't done any investigation of this but I guess it would be >> possible. > > See above about the difference between tasks and DebTags. That's probably a bug and should be reported against the binary package in question. If it's a game but it is not in section games, something went wrong. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature