Re: RFS: naev
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
Reply to: