[aur-general] Moving some popular games from AUR to community

[Lauri Niskanen]

On 08/15/2010 07:02 PM, Angel Velásquez wrote:
> On Sun, Aug 15, 2010 at 11:03 AM, Loui Chang<louipc.ist at 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>