<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 21, 2013 at 12:05 PM, Kevin Fenzi <span dir="ltr"><<a href="mailto:kevin@scrye.com" target="_blank">kevin@scrye.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">
Some questions for you:<br>
<br>
- Is the source available for anyone to download/use?<br>
I can't seem to see it off hand on <a href="http://ftp.redhat.com" target="_blank">ftp.redhat.com</a>.<br></blockquote><div><br></div><div>The source rpms can be found at:<br><a href="http://ftp.redhat.com/redhat/linux/enterprise/5Client/en/RHDevToolset/SRPMS/">http://ftp.redhat.com/redhat/linux/enterprise/5Client/en/RHDevToolset/SRPMS/</a><br>
<a href="http://ftp.redhat.com/redhat/linux/enterprise/6Workstation/en/RHDevToolset/SRPMS/">http://ftp.redhat.com/redhat/linux/enterprise/6Workstation/en/RHDevToolset/SRPMS/</a><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">
- How do you propose handing the difference in lifecycle? SCL is saying<br>
3 years next to RHEL's 10. What happens at those points? Everyone<br>
breaks and needs to rebuild anything that uses them?<br></blockquote><div><br></div><div>The details of the life cycle can be found here:<br><a href="https://access.redhat.com/support/policy/updates/dts/">https://access.redhat.com/support/policy/updates/dts/</a><br>
<br>This part is definitely more complex thank I'd like. My initial thought is that ideally the packages would just move to the newer released version of the devtoolset, but there's nothing that would break if they just stayed on the release they were already using. The devtoolset is also a very developer facing package and not used by the general userbase, so it's definitely annoying/frustrating that the life cycle is so short, but probably not quite as big of a deal as it would be with other types of package.<br>
<br></div><div>Having said all that, some sort of official policy would need to be in place, but I'm definitely open to ideas/input on this part of it, because I'm still not sure what I think the best solution for this is.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- I also wonder about CentOS/SL/Other users. Could they use these<br>
packages at all?<br></blockquote><div><br></div><div>Yes, devtoolset 2.0 was just recently released and still being worked on, but devtoolset 1.1 is available at:<br><a href="http://people.centos.org/tru/devtools-1.1/" target="_blank">http://people.centos.org/tru/devtools-1.1/</a><br>
<a href="http://ftp.scientificlinux.org/linux/scientific/6.4/i386/external_products/devtoolset/" target="_blank">http://ftp.scientificlinux.org/linux/scientific/6.4/i386/external_products/devtoolset/</a><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">
While EPEL could adopt different rules or setup than Fedora, I don't<br>
think our users want us to be making radical changes.<br>
<br>
I am also wondering if a side repo on <a href="http://repos.fedorapeople.org" target="_blank">repos.fedorapeople.org</a> or the<br>
like would be a better fit for this.</blockquote><div><br></div><div>I understand the concern here and maybe some sort of side repo (EPEL-dt or such) would be the right idea. The reason I'd like to get it as part of the EPEL is that the EPEL has a certain feel of "official" about it since it's sponsored by the Fedora community. I definitely could host the rpms for the ODB compiler myself, but then it doesn't have that same "stamp of approval" that I'm looking for by having it be part of the "standard EL process".<br>
<br></div><div>Dave<br></div></div></div></div>