<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 10:26 AM, SKRZYNIARZ Alexandre <span dir="ltr"><<a href="mailto:alexandre.skrzyniarz@fr.thalesgroup.com" target="_blank">alexandre.skrzyniarz@fr.thalesgroup.com</a>></span> wrote:<br><span class=""></span><br><span class=""></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>So, if I understand well, if we cannot work on source splitting, we have<br>
the following choices:<br>
<br>
1) fix the licensing problem. I guess that if it is not fixed yet, there<br>
is some complex issues involved.<br>
<br></blockquote><div><br></div><div>The problem is some files in the IDL generator belong to Sun Microsystems. The license is incompatible with the Debian guidelines and, IIRC, it may even be incompatible with other files in TAO.<br><br></div><div>An alternative IDL generator (C++11-based) has been under development for some time but so far, it has not replaced TAO because it is incomplete. Johnny may have more details, I think it was being developed by Remedy.<br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) I don't know if this is acceptable from a Debian Policies point of<br>
view, but can we move the ACE/TAO source package to contrib, and build<br>
binary packages that goes either in main or contrib from it? That would<br>
prevent the need to split the sources.<br>
<br></blockquote><div><br></div><div>IIRC Debian Policy does not allow that. If your source package is in contrib, then binaries belong to contrib.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3) Downgrade ACE from main to contrib. Therefore, no source splitting<br>
would be necessary. I'm not sure of what would be the consequences for<br>
main packages that depend on ace packages.<br></blockquote><div><br><br>That's an alternative we would rather avoid because 
most users do not enable contrib, therefore, they would never get to 
know ACE.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
4) Ship my patch as it is in the ACE/TAO distribution with some<br>
documentation for deployment, so that end users can build their own<br>
packages with ease if they need tao debian packages.<br>
<br></blockquote><div><br></div>ACE+TAO is a complex beat to maintain. Currently, the debianbuild directory contains essentially the official Debian packaging, which Johnny updates from time to time. Prior to that, there was a broken packaging. In fact, TAO is quite more complex to maintain than ACE.<br><br></div><div class="gmail_quote">Other alternatives:<br><br></div><div class="gmail_quote">5) Someone provides funding for the split packaging<br><br></div><div class="gmail_quote">6) Someone joins the pkg-ace-devel group and helps us do the splitting in our spare time<br><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The "all-in-one" source tarball is pretty convenient when building libraries on Windows and to distribute yourself but is a nightmare for distributions. E. g. I would like to package OpenDDS for Debian but it requires such a huge effort (ACE, TAO, DAnCE, then fixing the OpenDDS build system and probably source) that currently we do not have any DDS in Debian or its derivatives :-(<br></div><div class="gmail_quote"><br clear="all"></div><br>-- <br><div class="gmail_signature">Pau Garcia i Quiles<br><a href="http://www.elpauer.org" target="_blank">http://www.elpauer.org</a><br>(Due to my workload, I may need 10 days to answer)</div>
</div></div>