<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 17, 2013 at 8:33 AM, Marcela Mašláňová <span dir="ltr"><<a href="mailto:mmaslano@redhat.com" target="_blank">mmaslano@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 09/16/2013 08:25 PM, Toshio Kuratomi wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
== Build & Distribution ==<br>
* What are the impacts on the build system?<br>
</blockquote>
Until now we used internal instance of koji. I can sum up what we did there.<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* How are we preventing build problems from the mainline package<br>
from interfering with the scl package and vice versa?<br>
</blockquote>
There are no build interference problems. Package has specific name.<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* How are we allowing for a package to be built in more than one scl?<br>
</blockquote>
Didn't solve yet. We related build targets (collection) with branch. How to build for more collections is a good question for our releng. But do we need it?<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* How are we allowing for differences between scls? (ie:<br>
ruby1.9.3 scl with rubygem-foo1.0; ruby2.0 scl with rubygem-foo2.0)<br>
* How are we preventing build problems from one scl from<br>
interfering with a different scl?<br>
* Remi mentions that he thinks it would be done in a separate<br>
branch. Would we need a branch per scl that the package is built in?<br>
</blockquote>
Can't happen. Every branch is set to build in some tag. Packages tagged in one tag are shipped as one collection. You are able to inherit from one tag to another.<br>
As I said I prefer branch per collection. How else would be tags defined?<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* How do SCLs get distributed?<br>
* Is this a "separate repo" or is it just in the normal repo(s)?<br>
</blockquote>
Currently separate repo.<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* (toshio) Both. Some SCLs can go into Fedora Commons which<br>
would continue to have one repo. SCLs in the outer rings would have<br>
some separate structure.<br>
</blockquote>
Agreed.<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Build section would benefit from minor sections, perhaps:<br>
"Overview," "Testing" and "Example"? Sections need a bit more color to<br>
be understandable.<br>
<br>
</blockquote>
I'll add it.<br></blockquote><div><br></div><div>I would like to request that one more question/issue be addressed in this section.<br><br>Red Hat has made a GREAT tool available in the devtoolset ( <a href="https://access.redhat.com/site/documentation/Red_Hat_Developer_Toolset/">https://access.redhat.com/site/documentation/Red_Hat_Developer_Toolset/</a> ), but currently there's no way to take advantage of it in the EPEL. Can a plan to enable the use of the devtoolset for Koji builds for the EPEL for EL 5/6 be discussed as well?<br>
<br></div><div>The hope is that then packages that make use of the devtoolset could be created and then people who have subscriptions to the devtoolset could make use of them.<br><br>For example, I am working on packaging odb ( <a href="https://bugzilla.redhat.com/show_bug.cgi?id=975310">https://bugzilla.redhat.com/show_bug.cgi?id=975310</a> ), but it requires gcc 4.5 or greater for plugin support and that is only available on EL 5/6 through the devtoolset. So if it was possible to build on Koji using the devtoolset, then it would enable odb to be packaged for EL 5/6 and then those with access to the devtoolset could make use of it.<br>
</div><div><br></div><div>Thanks,<br>Dave<br></div></div></div></div>