Stephen John Smoogen wrote:
On 27 January 2018 at 15:41, Todd Zullinger <tmz(a)pobox.com>
wrote:
> I'm not sure if we want to limit the package set to
> devtoolset* via includepkgs or not. I did so in the above
> commit and have tested it very lightly. Restricting the
> packages may help prevent packages from accidentally pulling
> in bits from SCLo beyond the intended devtoolset packages.
>
If that works, I don't have a problem with that.
I think it does, but I worry that I'm missing some oddity in
yum/dnf/mock parsing of the single config file. I tested
with mock-1.4.8 on Fedora 26. Moving the epel repo section
after the sclo* repos I was still able to install epel
packages. I was worried that the includepkgs might not be
properly limited to the sclo repos, but it seems like it is.
It's easy enough to remove it if that proves incorrect with
wider testing.
> Technically, can't this be supported in epel-6 as well?
> (Please pardon me if I have overlooked a decision to only
> support DTS in epel-7.)
>
I don't know of any reason it would not work in EL-6 either. The spec files
I found using devtool-set only set it to rhel 7.
Yeah, I imagine we're at the point where most people
building things which require a newer compiler are moving to
EL-7. I could have used it while trying to build znc-1.6
for EL-6 a year or so ago.
(I ended up building znc with clang instead. I was going to
send the patch to the znc maintainers in EPEL, but it got
dropped in EL-6 before I had time to do so.)
> We'll also have to limit this to x86_64, won't we? I
didn't
> see any other architectures with SCLo support in CentOS. If
> I've overlooked them and someone can point me to them, that
> would be great. If not, we'll just want to append
>
> && %{_arch} == x86_64
>
> Maybe a macro can be added to epel-rpm-macros simplify this.
> That would be one place to edit if/when additional relases
> and architectures are added to SCLo.
>
I thought aarch64 was also supported for this.
It looks like the devtoolset bits are still in the sclo
testing repositories for aarch64¹. We could potentially
enable those in the mock configs if they're ready for more
testing. Or we can wait for them to reach stable.
If we end up with some macro to enable things, then we'd
just have to update epel-rpm-macros and the next builds of
packages which use them would work for aarch64. I'm sure
the various arch support across RHEL/CentOS/EPEL is a lot of
fun for everyone.
¹
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/
Thanks,
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reality is that which, when you stop believing in it, doesn't go away.
-- Philip K. Dick