EPEL Access to devtoolset in ?

Dave Johansen davejohansen at gmail.com
Sat Sep 21 19:07:01 UTC 2013


On Fri, Sep 20, 2013 at 8:44 PM, T.C. Hollingsworth <
tchollingsworth at gmail.com> wrote:

> On Fri, Sep 20, 2013 at 2:23 PM, Dave Johansen <davejohansen at gmail.com>
> wrote:
> > Part of the confusion may also come from the fact that the binaries
> > generated by devtoolset are standalone and can be run on vanilla
> installs of
> > RHEL 5/6 (i.e. without the devtoolset installed). So generally the
> > devtoolset is only needed during build time, but since the ODB compiler
> is a
> > plugin for gcc, the devtoolset is required for it's use when generated
> code
> > for use with the runtime.
> >
> > In summary, the devtoolset requires the appropriate subscription from RH,
> > but that is the point of my request. I would like to request that
> devtoolset
> > be made available on Koji so it can be used to build certain packages.
> The
> > idea is that then it will build the rpm on the server and it will be
> > available in the EPEL (but not the devtoolset itself). This means that
> > anyone who would want to use this package would need to have the
> devtoolset
> > installed, so it doesn't violate any of the RH/EPEL policies, but would
> > enable the use of the devtoolset with the EPEL.
>
> As you indicated in the other thread, the devtoolset channel is only
> included in
> developer RHEL subscriptions.  I'd presume the vast majority of EPEL
> consumers
> have server-type subscriptions, so they wouldn't have access to it,
> correct?
>
> That kind of sucks—there would be packages in EPEL that would have broken
> deps
> for a lot of EPEL users and no real way of indicating to those users what
> the
> problem is.  :-(
>
> What about CentOS and Scientific Linux?  These are 100% fully supported
> targets
> for EPEL [1] and cannot be ignored.  If they have no access to it, it
> shouldn't
> be used in EPEL.  On the other hand, if most of those users have access to
> the
> necessary dependencies, it might lessen the severity of lack of access to
> bona
> fide RHEL users in some peoples' eyes.
>

There are rebuilds of devtoolset by both the CentOS and Scientific Linux
guys. It obviously comes without the support that you get with the RedHat
subscription, but it's still an option and is available to anyone (not just
the CentOS or Scientific Linux guys). The repos can be found at:
http://people.centos.org/tru/devtools-1.1/
http://ftp.scientificlinux.org/linux/scientific/6.4/i386/external_products/devtoolset/


> In general, it seems your package is much more suited for a fedorapeople
> repo or
> similar.  It doesn't seem to be generally useful to the vast majority of
> EPEL
> consumers, just to users with a very limited set of RHEL subscriptions.
>  What's
> the point of making something available in EPEL if the vast majority of
> EPEL
> users can't use it?
>

I don't really get this line of reasoning. Is "generally useful" now a
requirement to be part of the EPEL? I've always had the understanding that
if it's useful to someone on RHEL, they're willing to maintain it, and it
makes it through the approval process, then it's ok to include in the EPEL.
I recognize that RedHat has made the use of the devtoolset unnecessarily
complex because of the additional subscription that's required, but that's
why I want to start this discussion. I'd like to help the community figure
out how to make use of this very useful tool (the devtoolset) and be able
to add to the excellent set of packages that the EPEL already is.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20130921/2922027b/attachment.html>


More information about the epel-devel mailing list