EPEL Access to devtoolset in ?

[Dave Johansen]

http://developerblog.redhat.com/2013/09/12/rhscl1-ga/
I know that the devtoolset requires an additional subscribe to get
access, but is there a way to make use of it in the Koji build process
so that those who are subscribed to the devtoolset can make use of the
package that uses it in the EPEL?

Thanks,
Dave

[Kevin Fenzi]

On Mon, 16 Sep 2013 10:43:50 -0700
Dave Johansen  wrote:
> http://developerblog.redhat.com/2013/09/12/rhscl1-ga/
> I know that the devtoolset requires an additional subscribe to get
> access, but is there a way to make use of it in the Koji build process
> so that those who are subscribed to the devtoolset can make use of the
> package that uses it in the EPEL?

EPEL strives to use Fedora packaging guidelines.

from:
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#...

"Software Collections (as defined here) are not permitted to be built
or enabled in official Fedora packages."

Until there are Fedora guidelines for them, no way EPEL is going to
enable them blindly, sorry. ;)

There is work underway to craft guidelines for them, you might look at
assisting in that effort and adding needed bits for using them in EPEL
too.

kevin

[Dave Johansen]

On Mon, Sep 16, 2013 at 11:08 AM, Kevin Fenzi  wrote:
> On Mon, 16 Sep 2013 10:43:50 -0700
> Dave Johansen  wrote:
> > http://developerblog.redhat.com/2013/09/12/rhscl1-ga/
> > I know that the devtoolset requires an additional subscribe to get
> > access, but is there a way to make use of it in the Koji build process
> > so that those who are subscribed to the devtoolset can make use of the
> > package that uses it in the EPEL?
>
> EPEL strives to use Fedora packaging guidelines.
>
> from:
> https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#...
>
> "Software Collections (as defined here) are not permitted to be built
> or enabled in official Fedora packages."
>
> Until there are Fedora guidelines for them, no way EPEL is going to
> enable them blindly, sorry. ;)
>
> There is work underway to craft guidelines for them, you might look at
> assisting in that effort and adding needed bits for using them in EPEL
> too.

How can I get involved in that process? I would definitely like to
help out with enabling the support for them in the EPEL.

Thanks,
Dave

[Kevin Fenzi]

On Mon, 16 Sep 2013 20:32:41 -0700
Dave Johansen  wrote:
> How can I get involved in that process? I would definitely like to
> help out with enabling the support for them in the EPEL.

Join the packaging list and see this post just today: 
https://lists.fedoraproject.org/pipermail/packaging/2013-September/009525.ht...

kevin

[Dave Johansen]

On Mon, Sep 16, 2013 at 8:37 PM, Kevin Fenzi  wrote:
> On Mon, 16 Sep 2013 20:32:41 -0700
> Dave Johansen  wrote:
> > How can I get involved in that process? I would definitely like to
> > help out with enabling the support for them in the EPEL.
>
> Join the packaging list and see this post just today:
>
> https://lists.fedoraproject.org/pipermail/packaging/2013-September/009525.ht...

So after a little discussion on the packaging list, it was decided that
this is the right place to have the conversation (
https://lists.fedoraproject.org/pipermail/packaging/2013-September/009554.ht...).

I think part of the confusion may have come because I don't want to package
an SCL, but I want to make use of a specific SCL that RedHat has created.
The discussion going on in the packaging mailing list is about the
guidelines for how to create SCLs, so my request isn't really pertinent
there. Anyway, I'll try to describe the situation a little better.

There are two parts of ODB: 1) the compiler and 2) the runtime. The
compiler takes an input and generates C++ code that can be built against
and used with the runtime. The generated code and the runtime can be used
with gcc 4.2 or greater.

The issue is that ODB requires gcc's plugin support (
http://gcc.gnu.org/wiki/plugins ) to parse the input. Plugin support was
added in gcc 4.5 and only gcc 4.4 is available on RHEL 5/6. The devtoolset
makes a newer version available, which enables the use of the compiler and
not just the runtime.

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.

Thanks,
Dave

[T.C. Hollingsworth]

On Fri, Sep 20, 2013 at 2:23 PM, Dave Johansen  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.

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?

-T.C.

[1] https://fedoraproject.org/wiki/EPEL/FAQ#Are_EPEL_packages_available_only_for...

[Dave Johansen]

On Fri, Sep 20, 2013 at 8:44 PM, T.C. Hollingsworth <
[e-mail]> wrote:
> On Fri, Sep 20, 2013 at 2:23 PM, Dave Johansen 
> 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/d...
> 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

[Kevin Fenzi]

Some questions for you:

- Is the source available for anyone to download/use? 
  I can't seem to see it off hand on ftp.redhat.com.

- How do you propose handing the difference in lifecycle? SCL is saying
  3 years next to RHEL's 10. What happens at those points? Everyone
  breaks and needs to rebuild anything that uses them?

- I also wonder about CentOS/SL/Other users. Could they use these
  packages at all?

While EPEL could adopt different rules or setup than Fedora, I don't
think our users want us to be making radical changes.

I am also wondering if a side repo on repos.fedorapeople.org or the
like would be a better fit for this.

kevin

[Dave Johansen]

On Sat, Sep 21, 2013 at 12:05 PM, Kevin Fenzi  wrote:
> Some questions for you:
> Is the source available for anyone to download/use?
> I can't seem to see it off hand on ftp.redhat.com.

The source rpms can be found at:
http://ftp.redhat.com/redhat/linux/enterprise/5Client/en/RHDevToolset/SRPMS/
http://ftp.redhat.com/redhat/linux/enterprise/6Workstation/en/RHDevToolset/S...
> How do you propose handing the difference in lifecycle? SCL is saying
> 3 years next to RHEL's 10. What happens at those points? Everyone
> breaks and needs to rebuild anything that uses them?

The details of the life cycle can be found here:
https://access.redhat.com/support/policy/updates/dts/

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.

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.
> I also wonder about CentOS/SL/Other users. Could they use these
> packages at all?

Yes, devtoolset 2.0 was just recently released and still being worked on,
but devtoolset 1.1 is available at:
http://people.centos.org/tru/devtools-1.1/
http://ftp.scientificlinux.org/linux/scientific/6.4/i386/external_products/d...
> While EPEL could adopt different rules or setup than Fedora, I don't
> think our users want us to be making radical changes.
>
> I am also wondering if a side repo on repos.fedorapeople.org or the
> like would be a better fit for this.

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".

Dave