Qt packages necessaries to develop for Android

Andrew Lutomirski luto at mit.edu
Thu Jun 5 23:32:11 UTC 2014

On Thu, Jun 5, 2014 at 4:16 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Isaac Cortés González wrote:
>> But it is licensed under an Apache license, we can download the source and
>> build it ourselves.
> Yes, please contact the Replicant folks for how to rebuild the Android SDK
> from source. (Last I checked, they didn't document the procedure either, but
> they should know how to do it because they ship a rebuilt SDK.) We cannot
> ship Google's binaries, both because of the license of the binaries and
> because Fedora does not ship upstream binaries by policy. We have to build
> the SDK from source code (which will land in the SRPM, so it needs to be
> free from non-Free or patent-encumbered (e.g. MP* codecs) code; any bad code
> needs to be ripped out from the tarball).

The ripping things out of tarballs policy seems really weird to me.
It means, for example, that I can't compare the hash of the openssl
tarball to upstream's.

Is it really necessary?  I understand that Fedora can't ship anything
infringes on a patent, but I had the distinct impression that patents
didn't cover uncompiled source code.  It would be a lot simpler if it
were sufficient to merely patch it out in %prep or something.

Even for not-quite-free stuff, there are weird cases.  For example,
globalplatform's tarball [1] includes a couple of binaries.  There is
actually source available, and the license is fine, but the source
isn't in the tarball. [2]  I seriously doubt that Fedora would
infringe on anyone's rights by leaving the tarball as is in the SRPM,
but doing so is currently against policy.  The binary RPMs would be
identical either way.

Of course, if there is actually stuff in the tarball that isn't
redistributable, that's a different story.

If this is something that shouldn't be discussed here, I'll shut up.

[1] I'm thought about resurrecting this package, but dealing with
hacked up tarballs is such a mess that I don't really want to.

[2] I've never actually tried to build the thing, but I wouldn't want
to install the binary on anyone's system anyway.


More information about the devel mailing list