[Pkg-pascal-devel] Castle Game Engine build tool
Paul Gevers
elbrus at debian.org
Tue Feb 9 10:26:40 UTC 2016
Hi Michalis
On 07-02-16 18:35, Michalis Kamburelis wrote:
> It's all open-source and reproducible work, and could be rebuild by
> anyone or even automated. But I don't think it's in Debian's
> scope/interest to do it?
If this can be done with tools in Debian, I don't object too much. But I
really appreciate it to have build targets (maybe not run by default
thought) such that it can be VERIFIED that it can be rebuild. If we
can't build with tools in Debian, we need to strip (see below).
> I don't think you're interested in
> maintaining Windows library versions within Debian:) These libraries
> are useful only when packaging the game to Windows or Android. If you
> want to use them on Linux, you will probably want also cross-compiler
> stuff for Windows/Android, which is not provided in Debian anyway.
> (Even getting Android SDK in Debian is a task in progress as far as I
> know, https://wiki.debian.org/AndroidTools ).
Do I understand correctly that we could build the Windows/Android
libraries, but nobody running plain Debian could use them? Then I don't
think it is useful now to actually include them.
> So it seems to me that removing these libraries from Debian
> distribution, on Debian side, would be simplest. Just remove the
> mentioned dirs
>
> tools/build-tool/data/external_libraries/
> tools/build-tool/data/android/integrated-components/sound/
Ok. And if it can be easily verified that these libraries can be build,
than I don't object too much of having them in your tar ball. As long as
it's free and can be build with tools in Debian, than I have no strong
objections having them in the SOURCE. We will just not ship them.
> Removing them on my (CGE) side would mean that I prepare and upload a
> special tar.gz that is really only for Debian usage...
I see your point. So let's not do it. We can strip on Debian side if we
need to. Then, we just need to check carefully with ever new source from
you. Would it be too much to ask to make and maintain a target to strip
convenience copies from the tree, such that we can check that we
stripped everything that needs to be stripped?
Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20160209/e75f4225/attachment.sig>
More information about the Pkg-pascal-devel
mailing list