[Games] Status update

[Dmitry Marakasov]

* Hans de Goede (hdegoede at redhat.com) wrote:

>> I.e. being more upstream than repos. Now I understand, that seems
>> reasonable.
>
> Yes the idea is to work together to create one golden set of patches, so 
> that if a distro comes along who does not yet have a package can take 
> that and be all done. If we just have a repo with distro a has these 
> patches and distro b has these, then distro x will still have a lot of 
> pain figuring out which patches to use.
>
> And when we do this (a golden set of patches) it makes sence to no longer 
> maintain a patch set, but instead maintain a VCS, in which we do an 
> initial check in of the last upstream release and then commit the golden 
> patches one at a time on top of that.
>
> Then we could even consider releasing a tarbal from time to time, and 

Yep, that would be great. At least for FreeBSD ports, this way we won't
even need to keep pathes in our portstree. AFAIK, git allows on-the-fly
tarball generation (but maybe I saw that feature in some other VCS).

As we use MD5 and SHA1 checksums to verify distfile integrity, there
seem to be no problem with security this way, as maintainer verifies the
patch (diffing it to vanilla branch, or, if he's really paranoid, even
to original source package), then checking out tarball for specific
revision and verifying it with checksums will ensure that nothing is
changed.

On the other hands, that may create excess load on the serve and
sometimes confuse downloaders (FreeBSD uses fetch, and I think it
will save http://.../GetTarball?branch=xxx&rev=yyy as
GetTarball?branch=xxx&rev=yyy). To not have such problems (and also
make mirroring and other good things possible), making real tarball
seems to be better.

> doing a small boilerplate per game webpage, which contains a link to a 
> general page and a link to the latest tarbal.

I think wiki can do that, but that should be another set of per-game
pages "for users", not "for packagers". Instead of info about patches
and stuff there should be short info about the game, links, depends,
notes on building, maybe couple screenshots. Something resembling
those:

http://npush.sourceforge.net/
http://openlierox.sourceforge.net/

> The general page would describing out cross distro collaboration project 
> and that we make new "upstream" releases containing our fixes for those 
> who want want them.
>
> Then software cataloging sites like freshmeat have a place to point users 
> to whose distro does not have game X, so that DYI installs (and distro's 
> creating new game packages not aware of our project) will find our new 
> "upstream" release and use that instead of having to reinvent the wheel.

Agreed

> Apologies and welcome to out BSD friends. Whenever I write distro, please 
> read distro/OS

No problem for me.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru    http://www.amdmi3.ru