[Fedora-packaging] SCL Notes and Questions

Toshio Kuratomi a.badger at gmail.com
Fri Sep 20 05:02:26 UTC 2013


On Sep 19, 2013 9:12 PM, "Dave Johansen" <davejohansen at gmail.com> wrote:
>
> On Thu, Sep 19, 2013 at 4:59 PM, Toshio Kuratomi <a.badger at gmail.com>
wrote:
>>
>> On Thu, Sep 19, 2013 at 12:18 PM, Dave Johansen <davejohansen at gmail.com>
wrote:
>> > On Thu, Sep 19, 2013 at 10:47 AM, Ralf Corsepius <rc040203 at freenet.de>
>> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20130919/7553741b/attachment.html>


More information about the packaging mailing list