Not saying I'm opposed to this PR, but the distro.py file is not the right place to make this change. If a new release of distro comes out, we will likely blow away this file with the new one. And if we ever release on PyPI, we may drop many of these external modules altogether. I'm not sure where the right place to do this would be, but it would not be here.

Is there another place where the distro is defined or can be overwritten somehow? The compiler.yaml can be used to overwrite it, but I have had issues with that trick.

I would override it in lib/spack/spack/operating_systems/linux_distro.py. That's the file where we actually call external.distro. There are already hacks in there for Ubuntu.

Are there any open questions about this PR?

What are the open issues with this?

@tgamblin Could this be merged?

Is there any issue where the rationale for this PR is explained?

There isn't an open issue. I can create one if need be.

The main issue is that CentOS, RHEL, and SL should be reported as the same OS, but CentOS is reported differently than RHEL/SL.

The main issue is that CentOS, RHEL, and SL should be reported as the same OS, but CentOS is reported differently than RHEL/SL

I get that this is what the PR does, my question is more "why CentOS needs to be reported the same as rhel"?

When distributing software across OSG, we will end up on machines that are either SL or CentOS machines. They need to be reported the same for us to be able to use Spack's internal OS resolution.

Sorry, I still don't understand why you can't distribute software taking into account where the request comes from (software built for rhel to rhel machines, same for centos)?

If I look at the PR with my current understanding of things, this seems to me more a regression than a feature - Spack erroneously reporting centos as rhel.

It means that instead of two machines (SL/CentOS6 and SL/CentOS7), I need to operate 4 machines (SL6, CentOS6 SL7, and CentOS7) and build everything twice to distribute software. Are there any packages which rely on the difference between CentOS and SL/EL? Is there a way this feature could be turned on and off somehow rather than having to hardcoded?

Based on #1075 (comment) @gartung may also be interested in this PR.

@adamjstewart Thanks for the link. Actually I agree a lot more with what @tgamblin says:

I think it's useful to know that something was built on CentOS, in case that actually matters later for debugging. But that doesn't mean we couldn't allow Spack to have looser semantics on install. i.e., the user could allow using a CentOS-built binary if a RHEL one isn't available, or Spack could just know that these two are generally compatible. That would get you binary caching but it would also avoid losing information from the build.

than with this PR. @briedel If the problem is operating physical machines, we can work on constructing a binary cache using dockerized builds. I think that + the feature proposed in the quote above are better than reporting the wrong OS.

It is not about operating physical machines. It is about not having to compile and manage ~100 packages that we want to distribute. I would prefer if there were a knob like would allow me to say "I don't care about the difference in EL distros. They are all the same to me"

I understand why @briedel did this. Scientific Linux CERN 6 reports as RHEL6. CERN Centos7 reports as Centos7. For HEP purposes, they should both report as RHEL. This can be a patch that HEP applies to spack usage since it is HEP specific.

Let me rephrase the question. Where can I put in the knob that allows me to turn this on or off?

HEP operates a heterogenous grid of compute nodes. The only requirement imposed is binary compatibility with RHEL. There are many RHEL clones besides Centos and Scientific Linux. It would be preferable to build a package once for any RHEL6 clone.

Is it possible to use symbolic links in opt/spack to allow listing for common RHEL clones?

@alalazo Preferred solution is just to create a symlink?

@briedel this has aged long enough. We just applied this patch to our fork:
FNALssi#7

Sounds good @gartung Thanks.