On Fri, Jan 26, 2018 at 4:41 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
Several meetings ago, the EPEL Steering Committee took up the
1. Peter Robinson's DTS enablement request
A. What packages require it (chromium etc)
B. Is there a version in CentOS?
Yes, CentOS builds the DTS and makes it available via the SCL repositories 
i. If not is it possible for it to exist in CentOS?
ii. If not what work would a CentOS version take and how long?
iii. If not and not possible does this make EPEL non-workable/closed source
So because CentOS has it available all 3 of those questions are irrelevant.
C. What problems are known for getting it into Koji
i. Does it cause problems with normal packages
No, it doesn't. It doesn't "Provide" any of the core toolchains or any
other package so like any other package not in the core build root you
need to explicitly add it to the BuildRequires in the package spec
ii. Do users need to have any bits from it to work? [old yacc/bison
No, DTS has been available as part of the standard RHEL subscription
for _YEARS_ and is in use widely.
iii. Does koji have problems with this as another channel to work
No, just like extras/optional and any of the other additional channels
it has no impact, users need to explicitly add buildrequires to get
any of the packages into their buildroot.
iv. Does Fedora have the ability to get this channel
or need to use a different one (aka CentOS one if it exists)?
Yes, it's provided as part of the standard Red Hat el7 subscription.
Any RHEL user that had a standard RHEL subscription can add the
channel, this is no different from Optional/Extras so no different for
any of the other EPEL use cases.
At that time, EPSCO agreed that we are ok with this for just the
development toolkit. We are still needing to work out the following
1. How do we do this with mock so that people who rebuild with CentOS can do so.
For RHEL users they need to add the appropriate DTS channels, for
CentOS users they just have to follow the details in the CentOS wiki
2. How do we get Koji to do this
Add DTS to the sync process, add the new repos for all the supported
architectures to the koji external-repos as per
Server/Optional/HA/Extras that are already part of the el7.
3. What are the packaging guidelines that need to be put into EPEL
packaging guidelines as the SCL guidelines were never finalized and
the devtoolset is an scl that we would be building against.
The DTS isn't really a SCL, it's maintained by a completely different
team and is released on a different schedule. I would think it would
be covered by the same guidelines as the "Extras" repository which,
like DTS, provides additional toolchains such as Golang so what were
the extra packaging guidelines that were required when Extras were
made available in the el7 buildroot?
Any other questions you'd like to use to fillibuster this?