On Sep 19, 2013 9:12 PM, "Dave Johansen" <davejohansen@xxxxxxxxx> wrote:
>
> On Thu, Sep 19, 2013 at 4:59 PM, Toshio Kuratomi <a.badger@xxxxxxxxx> wrote:
>>
>> On Thu, Sep 19, 2013 at 12:18 PM, Dave Johansen <davejohansen@xxxxxxxxx> wrote:
>> > On Thu, Sep 19, 2013 at 10:47 AM, Ralf Corsepius <rc040203@xxxxxxxxxx>
>> > wrote:
>> >>
>> >> Correct me if I am wrong, but to my knowledge, RH's devtoolset is only
>> >> available to RH customers, which would mean EPEL can not use it.
>> >
>> >
>> > Yes, 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.
>> >
>> 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 discussion.
>
> The devtoolset requires a "developer subscription" so it's not part of 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 ( http://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F )?
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 packaging scls.
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 of them.
(P.s. thanks for participating in this discussion. Your question sparks one that I need for the guidelines: there seems to be a slight preference 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.)
-Toshio
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
