Re: RFS: naev
On Sat, 09 Jul 2011 at 18:34:09 -0700, Vincent Cheng wrote:
> Thanks for the review. Please also consider reviewing my most
> up-to-date packaging in the Debian Games svn repository; my Naev
> packaging at mentors.d.n is heavily outdated at the moment, mostly
> because I'm getting tired of having to upload a 200 MB tarball every
> time I want to make a minor change to my packaging.
Have you considered splitting the package, along the same lines as OpenArena
and Nexuiz? Even if your upstream always releases the code and data together,
you're much more likely to need to fix bugs in the packaging or code than
you are in the data. If you keep the .menu files and other Debian additions
with the code, you'll only need to upload a relatively small .deb for fixes
to either the code, or the menu entries etc.
There are basically three ways you could go:
* Single monolithic source package, like Wesnoth. As you have noted, this is
a pain to upload!
* One source package for code (and other small/easy-to-patch things like menu
entries and man pages), one for data, like OpenArena in squeeze.
naev Depends: naev-data with version constraints. This is quicker for
you to upload, but if the -data package is too large, it won't get into
debian-cd CD releases, only DVDs and BluRays (I think the cutoff for CDs
is a couple of hundred MB).
* One source package for code, several for data, like OpenArena in
sid/experimental. naev Depends: naev-textures, naev-music, naev-data
(or whatever) with version constraints. When I asked the ftp-masters,
Mark Hymer said they didn't object to this. Steve McIntyre (debian-cd
maintainer) recommended aiming for about 50 to 100 MB when splitting
data packages like this.
> As far as I understand, it's not an issue that blocks Naev from
> entering the archives (while binaries/executables need to be able to
> be built from source code, I don't think policy mandates that images
> must be built/rendered from source...if that's the case, an awful lot
> of packages currently in Debian would have to tweak their build
> system).
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.
S
Reply to: