[bt-devel] PDFs and other object files in source tarballs

[Jonathan Marsden]

Martin Gruner wrote:

> I agree with you on the definitions of source and derived files. We
> _do_ distribute the source files and therefore fulfill the
> stipulations of the GPL.

True, as long as you know for sure the two can never get out of sync in 
what you distribute, so the binary blobs really *are* derived from the 
source that you are distributing and not from some slightly different 
version of the source.  If they are separately checked into svn, I'm not 
sure how easy that is to be sure about.

But, as I understand it (I'll have to try to get a more expert opinion 
if I can't persuade you!), derived files that say they are GPLed can't 
be included in Ubuntu source packages and so in package source tarballs. 
  I'm pretty sure the same applies to Debian, it's just that I know 
where to find Ubuntu packaging info more easily.

> Currently, our source tree does contain some derived files. All of
> them can be automatically created from the source files with a simple
> make call, _if_ the user has the required software installed. We need
> to document how that can be done.

Better, you probably want to set things up so that if the required 
software is present, they *are* automatically created at build time from 
source, and only if it is missing does the build process then fall back 
and depend on supplied derived files.  That way, at least the system 
does things right whenever it can :)

> Given that the only drawback is increased size of the tarball, but
> the benefits are
> a) less effort when building and installing BibleTime

I don't understand this one -- once the build system is set up 
correctly, the effort required by the human builder is the exactly same 
either way, he or she has to type make and press Enter.

> b) less required software to build and install BibleTime

(b1) This is not really valid for the *.qm files, I think -- you'll need 
a working Qt development environment anyway, so you'll have an lrelease 
binary installed as a part of that, as I understand it, on all 
platforms.  What additional software is needed to convert .ts files into 
.qm files?  It doesn't seem to me that this is a particularly resource 
intensive process, either.  Is Qt lrelease broken on Windows?

(b2) This is somewhat valid, for the HTML (and potentially PDF) 
documentation.  But given packaging systems with Build-Depends: lines 
and similar setups in other environments, obtaining that software is 
pretty straightforward, or even 100% automatic, in many or most build 
environments.

I think for Windows it would be great to have a .bat file that downloads 
and sets up a developers working environment for SWORD and BibleTime, 
but when I started down that path, the reaction I got was that it was a 
big mistake, everyone prefers using commercial GUI tools for everything 
in Windows... so I have ceased putting any effort into that, at least 
for now.

> I feel that I would like to keep the current approach.

It's your project, so your decision.

As I see it, there are drawbacks that (a) you are keeping binary blobs 
in svn for no real benefit, (b) having derived files included in the 
"source" tarball is unnecessary, confusing and (c) this probably (just 
my opinion, needs further verification!) breaks packaging requirements 
for some Linux distributions, so requiring packagers to do extra work 
for every release.

> Especially because we want to support platforms like Windows where
> not the entire toolchain is present. It would probably be possible to
> require packagers to get the full toolchain working even on windows
> or mac, but I don't see the need for it. We have to make a
> compromise.

Realistically, I can't get Ubuntu and Debian to "compromise" and change 
their rules, and apparently I can't persuade you to "compromise" and 
remove the files.  So, if I am understanding the rules correctly, and 
you want to keep the current approach, then the "compromise" you are 
suggesting is basically that I need to just "deal with it", and do extra 
work... which is not a "compromise" that I really like :)

> That said, you can easily strip the derived files and re-generate
> them if you have to. =) Use
>     make messages
>     make howto
>     make handbook
> to re-generate the files.

OK... if that is the final decision, then at some point (before any more 
BT packages are released by me) apparently I'll have to create makefile 
rules to download, unpack, remove derived files, and repack the tarball, 
and then add your make lines above to the package build process (patch 
either the build-debug.sh script or the top level Makefile, probably) so 
that they are generated (and deal with cleaning them up in the package 
clean rule, etc.).  The former is likely to be more work than the latter.

Jonathan