On Sun, Jul 10, 2011 at 9:50 AM, Simon McVittie wrote: > In my understanding of Policy and the DFSG, there's a difference between > data not being built from source code, and data not being accompanied by > source code at all. > > Data not *being built from* source code is a technical bug: it means upstream > haven't given you a deterministic build system (and you haven't been able > to construct one). It's a bug, but not necessarily a fatal one. > > (OpenArena has that bug too - upstream don't provide a build system for the > data, probably because it involves a lot of manual exporting; the derived > files are checked-in to svn alongside the source files.) > > Data not *having* source code is a Policy/DFSG bug. In principle, for each > file in the binary package, the DFSG require you to include corresponding > source code in the source package, even if it isn't actually rebuilt. > > For some (most?) game upstreams, it's difficult to tell what the corresponding > source code *is* (is image.jpg the preferred form for modification or is > there a .xcf version somewhere? we just don't know), but you should at least > include a best-effort guess at what the source is. (OpenArena also has this > problem; the source packages in sid/experimental contain my best guess at > what the source was.) > > Where possible, the most reliable way to know that the "source" you're > providing is the actual source is to rebuild it, but I realise this isn't > always feasible, particularly for upstreams whose background is game modding > rather than Free Software.
In the case of naev, I was able to find the source code by interrogating upstream on the #debian-games IRC channel. I found out that the pre-built data is in the same VCS as the engine and the source for the data exists, but is in two separate git repositories (one shared with vegastrike/adonthell), is rarely rebuilt and currently the 3D stuff cannot be rebuilt with current tools, since the Blender Python API changed very incompatibility. git://github.com/bobbens/naev.git https://github.com/Deiz/naev-artwork.git http://pingus.seul.org/~grumbel/vegastrike.git/ Personally I would not be willing to upload naev in its current state. Ideally there would be multiple source packages that build their respective data/code properly into corresponding binary packages, perhaps like this: naev naev-engine naev-tools naev-gfx naev-ships naev-asteroids naev-people Fedora on the other hand are fine with this situation: http://cedarandthistle.wordpress.com/2011/07/09/naev-is-now-in-fedora/ -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAKTje6E-7vXAkdjR=zmqvuio4u76orswst3vcvvbq+40n1x...@mail.gmail.com
