On 08/15/2010 07:02 PM, Angel Velásquez wrote:
On Sun, Aug 15, 2010 at 11:03 AM, Loui Chang<louipc.ist@gmail.com> wrote:
On Sun 15 Aug 2010 08:30 +0200, Sven-Hendrik Haase wrote:
On 15.08.2010 07:50, Thomas Dziedzic wrote:
I would say yes to all of them, but what about the arch-games repo? How will these two coexist?
arch-games is unofficial and has proven to be rather unreliable in the past. I'd like at least the most popular games to receive official blessing and support in our bug tracker. To me this seems like it would be the most consistent and easy way for users. The games would then either be removed from arch-games or not, it's their choice. Duplication of efforts is probably not a good thing, though.
Well, the only way to fix that would be to use it and contribute to it. If you shun arch-games then it's more likely to remain in the dark, so I encourage everyone to use arch-games and maintain their game packages there.
arch-games is a good option IMO, big packages repo, was my original idea (a year ago), but ... having many repos can be a mess (I agree in this part with you Sven), but as I said, we are a 30 gb or more distro on binary packages, that doesn't mean that we have few packages, other distros have more architectures (case Debian) or their compression system on the packages is very old fashioned and poor.
Splitting games or big packages as much as can be splitted is the way to go, but as I said, if the maintainer can handle the situation, then I won't have any issue accepting games, maybe in a short-future I will play them =P
One possibility would be some kind of a delta encoding upgrade system. It doesn't help when it's the case of just binary executables, but when we have a game with lots of data files you don't probably need to update everytime all of those. Splitting packages is a solution for this issue, but a general synchronization based on single files would do the job in a modern way. In short: Why to compress a set of binary data files to a one huge package? -- Ape <Lauri Niskanen>