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

[Greg Hellings]

I'm not going to get into the intricacies of what goes on in the Linux
world or packaging (and how I think Ubuntu and Debian are far off base
the more I hear about them).  Just from a Mac and Windows builder
vantage point:

Not all of the tools required are available or readily available for
Windows.  It's possible that not all of them are available for Mac
either, but I haven't really looked there.
Some time ago I ran into an issue when I tried to clean something in
the BibleTime directory, and it found a missing documentation file and
the build process tried to create it.  It couldn't find the required
command and, frankly, neither could I.
So I went back to the tarball, untarred the sources again, and there
was the file.  Part of the derived files? Yes.  A file I could have
derived in Windows without hurting myself trying to figure a way to do
that? No.

If Ubuntu and Debian don't want us to be part of their repositories
because we distribute as "source" a file derived from a file over
which our project has full copyright and has declared it part of the
GPL'd package (along with the actual "source" document), and which we
include because it makes building on systems other than the Holy Linux
a less burdensome task for other packagers, then I think Ubuntu and
Debian need to have a seriously introspective moment with themselves
and wonder why people find their requirements for inclusion
unnecessarily stilted.

--Greg

On Thu, Nov 19, 2009 at 2:49 PM, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
> 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
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
>