no anser? -- no help?
well -- after digging further building more debian like packaging, i finally found:
i'm still evaluating different solutions, to use this travis instructions for local debian builds without much superfluous code duplication, but it doesn't look very promising. to run travis on local docker intallations, you have to download gigantic images. from a practical point of view, this doesn't make sense for the local processing of .deb-sources.
sure, i understand all the difficulties to manage multi platform project like natron and all the complicated requirements to produce working binaries frequently in an effective manner. therefore i really respect the choice of it's maintainers to use complex services like travis for this kind of jobs, but GNU licensed code and the debian project are very demanding in this respect:
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. (GPL v2)
a package, that can not be compiled by users themself on their local machine, simply wouldn't be accepted in the official debian distribution and their strict notion of "open source".
it's very complex field of troubles. Guus Sliepen gave an interesting talk about this family of issues recently at FOSDEM:
i'm still working on a solution, to solve this requirements for particular case of natron on debian based distros and it's compilation/installation requirements.
it would be really helpful, if the involved natron core developers could explain their strategies of packaging a little bit more traceable and share their ideas, how we should add other compiling/packaging options without unnecessary high maintenance code duplication.