[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: assaultcube-data (updated package)

On 10/07/11 15:18, Michael Tautschnig wrote:

Dear mentors,

I am looking for a sponsor for the new version
of my package "assaultcube-data".

It builds these binary packages:
assaultcube-data - data files for AssaultCube
assaultcube-server-anticheat - AssaultCube server with closed source
anti-cheat module

The changes are:
* Update manpages
     - CC-BY-NC-SA (previous license was incorrect given content used)
     - Few formatting fixes
   * Update debian/copyright
     - Note license of manpages
     - "Files:" headers pointing at directory instead of license file.
   * Update debian/rules to dh7 format
   * New package: assaultcube-server-anticheat, installs upstream
server binaries
   * Create a wrapper script for the server with "--help" for manpage
   * Don't repack anymore.


Thanks a lot for updating this package. Yet the new non-repacking leaves some
doubts to me:

- "Don't repack anymore." is a nice hint that something has changed, but yet it
   left me to find this out myself via the debdiff.
- Using "repacknot1" as version appears to be a cruel hack. Ideally we'd have a
   new upstream version that could be packaged, but if that doesn't happen
   soonish, we'll have to live with that hack. (Introducing an epoch doesn't seem
   like a better solution either...)
- Why do server binaries belong to a "data" package? Isn't that just a hack to
   avoid a new source package?
- The original license appears to disallow re-packaging/splitting, hence there
   must be some exclusive exception provided to Debian. This is, however, not
   detailed in the copyright file.

Best regards,


- True, I've changed it to read "Upstream tarball no longer repacked; binaries not removed since used", would this be reasonably verbose?

- Yeah, is in the works, but when is very uncertain (maybe this year...). I discussed the renaming on IRC (mentors/games) and it seemed like this was the most reasonable solution.

- Would splitting it into two source packages be better, it seems a tad unnecessary? Upstream distributes one "AC" package with precompiled binaries and data for "compile-less" usage (which Debian uses only for data currently), and an AC-source package, which Debian uses to create the packages with the binaries. Since the binaries comes in the upstream tarball which Debian calls "-data" I guessed it would be best to use this source package as-is..

- Noted (complicates the current deletion of the binaries as well, I guess), I've sent the question of special permission for the Debian project to the main project people, we'll see where that discussion leads.

Thanks for reviewing! :)

Reply to: