Am Dienstag, den 12.07.2011, 16:48 +0200 schrieb Arand Nash: > On 10/07/11 15:18, Michael Tautschnig wrote: > > Hi, > > > >> Dear mentors, > >> > >> I am looking for a sponsor for the new version 1.1.0.4+repacknot1-1 > >> 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, > > Michael > > > > Hello. > > - True, I've changed it to read "Upstream tarball no longer repacked; > binaries not removed since used", would this be reasonably verbose? Since the game engine is apparently derived from the FLOSS Cube 2 engine, why should we ever want to ship untrustworthy obscure binary blobs? > - 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.. We usually split up into engine and -data packages as it can save a lot of bandwidth if we have to change or patch something in the engine. With separate source packages an update to the engine package only affects the engine binary packages. Cheers - Fuddl
Attachment:
signature.asc
Description: This is a digitally signed message part