Netpanzer

Toshio Kuratomi a.badger at gmail.com
Wed Aug 29 17:18:44 UTC 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans de Goede wrote:
> Toshio Kuratomi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Jon Ciesla wrote:
>>> With release 0.8.2, upstream has merged the program and data
>>> tarballs. I'm thinking of merging netpanzer-data into netpanzer and
>>> obsoleting
>>> netpanzer-data.  Any objections?
>>>
>> Isn't the netpanzer data large and not subject to as much change as the
>> engine?  If so, there are still reasons to keep the data separate from
>> the game engine.
>>
> 
> If upstream distributes things in one tarbal, they should be in one
> SRPM, and then splitting is no use.
> 
It is of use to end users.  Not having to redownload the data everytime
the game engine is updated is a win for end users.

The downside is that you end up with two SRPMs of equal size (due to the
new tarball containing the data files both for the data and the engine
package).

> Also AFAIK netpanzer doesn't get frequent package updates.
> 
That's been my experience in the past as well.  But the real question is
whether the data files are updated at the same frequency as the
engine... which has several permutations as well:

1) Does upstream update the data files when they release a new netpanzer
tarball or do releases get made where the data files are unchanged?

2) Is the package maintainer going to backport changes from upstream
ever?  ie: if a segfault or security vulnerability were discovered in
netpanzer, will you backport a fix from upstream instead of
waiting for them to make their next release?

If these cases occur then end users will appreciate only having to get a
new version of the engine without having to download the data.

- -Toshio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG1ap0X6yAic2E7kgRAhBIAJ9K82wxcTNnVeBLkSXpncYc/8R5FgCdFf8v
8hmH1En6fJh/8Sbq+LzoGgg=
=puCA
-----END PGP SIGNATURE-----




More information about the Fedora-maintainers mailing list