On Thu, Sep 19, 2013 at 10:02 PM, Toshio Kuratomi <a.badger(a)gmail.com>wrote:
On Sep 19, 2013 9:12 PM, "Dave Johansen" <davejohansen(a)gmail.com> wrote:
> On Thu, Sep 19, 2013 at 4:59 PM, Toshio Kuratomi <a.badger(a)gmail.com>
>> On Thu, Sep 19, 2013 at 12:18 PM, Dave Johansen <davejohansen(a)gmail.com>
>> > On Thu, Sep 19, 2013 at 10:47 AM, Ralf Corsepius <rc040203(a)freenet.de
>> > wrote:
>> >> Correct me if I am wrong, but to my knowledge, RH's devtoolset is
>> >> available to RH customers, which would mean EPEL can not use it.
>> > Yes, the devtoolset requires the appropriate subscription from RH,
>> > is the point of my request. I would like to request that devtoolset
>> > available on Koji so it can be used to build certain packages. The
>> > that then it will build the rpm on the server and it will be
>> > the EPEL (but not the devtoolset itself). This means that anyone who
>> > want to use this package would need to have the devtoolset installed,
>> > doesn't violate any of the RH/EPEL policies, but would enable the use
>> > devtoolset with the EPEL.
>> This is a bit of a tangent from the comments on the packaging
>> guideline draft but in addition to Fedora passing draft guidelines,
>> needing a separate subscription from RH may run afoul of a different
>> EPEL Guideline -- the packages that EPEL bases against are not all of
>> RHEL but only ones that come/came with the base subscription. This is
>> a little ambiguous because this was figured out in the RHEL5 times but
>> RHEL6 has slightly different subscriptions/channels/what have you. I'm
>> not sure if the devtoolset you talk about will be a part of that or
>> not. If it isn't you (or someone) would need to package those up for
>> EPEL before they could be used to build other packages.
> As I was reading through the original email, I realized that this was
probably not directly to the issue being discussed here (i.e. the potential
use of an SCL in the EPEL rather than guidelines for packaging of SCLs in
Fedora/EPEL). But this is where I was asked to bring up the issue at, so I
brought it up here in hopes that it would be able to become part of the
> The devtoolset requires a "developer subscription" so it's not part
the base subscription. The devtoolset seems to be a new sort of animal when
it comes to RHEL subscriptions, so maybe this isn't true, but wouldn't
re-packaging it violate the rule about replacing packages (
Interesting. I was sure we didn't cover layered products because if we
did there would be certain classes of packages that are unbuildable.
Better ask nirik if that documentation is out dated.
>> Do note that pulling the devtoolset into EPEL's buildroot directly
>> from RedHat isn't something that we'd decide upon in the Fedora
>> Packaging Committee. EPEL people sent you here because what we (FPC)
>> decide about SCLs in Fedora will inform their views on whether and how
>> EPEL should implement SCLs. So they're waiting on us but their
>> decisions will be separate.
> Like I said before, at least in regards to this issue, I'm more
interested in enabling "the use of an SCL" rather than enabling "the
packaging of one". So what can I do to help make sure that the final
guidelines allow for that sort of use case? Because it seems that without
the guidelines allowing for that, the EPEL guys won't even be able to make
a decision at all.
If it's purely about using an scl then there's nothing that this guideline
discussion will do to aid your purpose. This discussion is just about
You may need to go back to epel and make that clear. At which time they
*may* say that devtoolset needs to be packaged in epel. And then (if I
understand correctly) you may need to come back to this discussion to make
sure you'll be able to package the scl that you need for epel. And finally
after all that's done you'd be able to build the package you really want.
Sorry for the somewhat circuitous nature of this path... scls are a bit
new and we (fedora packagers, fpc, epel) are all learning about all aspects
No problem. I know that SCls are still a new thing and that working out all
of the kinks and issues with new stuff takes some back and forth. I'll take
the conversation back to the EPEL and see if I can do a better job of
explaining the situation and get some traction there.
(P.s. thanks for participating in this discussion. Your question sparks
one that I need for the guidelines: there seems to be a slight
for non-scl packages to not be able to require scl packages. But your
situation brings up the question of whether it would be okay for them to
buildrequire an scl package.)
I'm still somewhat new to the whole packaging arena, but I would think that
not directly requiring an SCL would be a good rule. However, allowing
things like a BuildRequires with a requirement on a minimum version number
that can be satisfied by a SCL would be the right solution.
Right now, with the devtoolset that's not the case. It doesn't have a
Provides statement that indicates that it makes gcc 4.7 available, but if
it did and that was properly supported and used by the packaging, then it
would make its use a LOT easier. I realize that the devtoolset is probably
a little different than most SCLs because it's a toolchain/compiler/etc,
but it would be nice if it "played nicer" with the whole packaging process.