Drop cos6 builds

[isuruf]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[h-vetinari]

Talk about an anti-climactic finish for the immense journey that cos6 has had in conda-forge... 😆

Closes conda-forge/conda-forge.github.io#1436

[mbargull]

Do we have a task list in some issue for this already?
If not, we could add it to conda-forge/conda-forge.github.io#1436 .
Things apart from the pinning changes that come to mind:

• adjust numbers of track_feature to sysroot_linux-64
  (somewhat obsolete due to {{ stdlib('c') }}; could be relevant for downstream users for a limited amount of time)
• docs
• (can be done later: remove linux-anvil-comp7 build files)

[h-vetinari]

adjust numbers of track_feature to sysroot_linux-64 (somewhat obsolete due to {{ stdlib('c') }}; could be relevant for downstream users for a limited amount of time)

AFAIU the idea was to drop the sysroot repodata hacks completely.

[jakirkham]

adjust numbers of track_feature to sysroot_linux-64 (somewhat obsolete due to {{ stdlib('c') }}; could be relevant for downstream users for a limited amount of time)

AFAIU the idea was to drop the sysroot repodata hacks completely.

cc @beckermr (in case you have thoughts 🙂)

[isuruf]

AFAIU the idea was to drop the sysroot repodata hacks conda-forge/linux-sysroot-feedstock#63 (comment).

That would break non-conda-build users of our compilers since they would be getting 2.28 and would not be able to run executables made with our compilers if they have __glibc<=2.27

[mbargull]

AFAIU the idea was to drop the sysroot repodata hacks completely.

That is a long term goal, yes.
Unless I'm mistaken, the prerequisite for that is {{ stdlib("c") }} usage -- which you've worked through for conda-forge.
For downstream users, we don't know when they'll use that.
Plus for non-conda-build compiles, people would also need to be explicit about the sysroot_linux-64 version they install.

[h-vetinari]

This is Matt's comment I referenced:

@beckermr: Yeah to be clear, once we remove the hacks @h-vetinari is referring to, conda will install the latest sysroot when a compiler is installed. That will be w/e the latest is at the time, which right now is 2.28 IIRC. It won't mean we ship the compiler without the sysroot.

---

@isuruf: That would break non-conda-build users of our compilers

We could teach them to install sysroot_{{ platform }} 2.x, just like they've installed gcc_{{ platform }} already. Sidenote: ~90% of the ecosystem are on 2.28+ already.

@mbargull: Unless I'm mistaken, the prerequisite for that is {{ stdlib("c") }} usage -- which you've worked through for conda-forge.

Yeah, we're set for that in conda-forge now (modulo old recipes, but the linter warns on misuse at least).

For outside use, we should document what support we provide. Given that we have no stated support for this, we IMO shouldn't be shy about asking users that want to manually install our production compilers (rather than compilers, where we could easily depend on 2.17) to do the necessary changes w.r.t. stdlib, rather than keep the sysroot hacks indefinitely.

[beckermr]

Even if we don't drop the hacks, I think we need to update them to make sure cos7 is highest priority.

[isuruf]

We could teach them to install sysroot_{{ platform }} 2.x, just like they've installed gcc_{{ platform }} already.

Not really. The compilers are pulled in with r-base and other packages.

[h-vetinari]

The compilers are pulled in with r-base and other packages.

Any reason we couldn't make those packages run-depend on {{ stdlib("c") }} (on linux), thus staying with 2.17?

[isuruf]

Then you wouldn't be able to change c_stdlib_version to 2.28 in downstream recipes/users.

[beckermr]

We could introduce the sysroot dependence only for the compilers metapackage maybe?

[h-vetinari]

Then you wouldn't be able to change c_stdlib_version to 2.28 in downstream recipes/users.

It could work if we had wrappers for each sysroot version. Not saying this packaging complexity is desirable, but perhaps it's still better than indefinitely keeping the track_features:

outputs:
  - name: _r-base  # same as current r-base
      ...
  {% for glibc_ver in ["2.17", "2.28"] %}
  - name: r-base
    build:
      string: ...{{ glibc_ver }}...
    requirements:
      run:
        - {{ pin_subpackage("_r-base", exact=True) }}
        - sysroot_{{ target_platform }} {{ glibc_ver }}  # [linux]
  {% endfor %}

We could introduce the sysroot dependence only for the compilers metapackage maybe?

That makes sense in any case IMO, but if we don't do contortions along the lines of the above, it seems we cannot get rid of the need to weigh down the newer sysroot.

[beckermr]

Ah sorry. We should be clear. There are hacks specifically for current_repodata.json. I think we should drop those. We still need the features etc unless always use stdlib which has other issues.

[beckermr]

I definitely wanted to drop all of the hacks but Isuru is right. Just keeping build number and the track features is manageable.

[h-vetinari]

How about we merge this PR and track other things in conda-forge/conda-forge.github.io#1436?

[beckermr]

One problem I noticed.

[beckermr]

Removing these lines will break the ability to set the linux version in smithy via os_version

https://github.com/conda-forge/conda-smithy/blob/9e4720fc497f45f45d7bd319a354c762992c530d/conda_smithy/configure_feedstock.py#L994

Maybe we keep them and set the default to cos7?

[isuruf]

You mean you want to keep supporting cos6 in some feedstocks?

[beckermr]

You mean you want to keep supporting cos6 in some feedstocks?

Right. there are two things. First yes, we no longer officially support cos6.

Second, are we deprecating os_version in smithy? If not, we need to keep the selectors here to account for smithy setting DEFAULT_LINUX_VERSION like this:

        # set the environment variable for OS version
        if platform == "linux":
            ver = forge_config["os_version"][f"{platform}_{arch}"]
            if ver:
                os.environ["DEFAULT_LINUX_VERSION"] = ver

We probably need to add them to add support for cos8 or higher, but in another PR maybe.

[isuruf]

Second, are we deprecating os_version in smithy? If not, we need to keep the selectors here to account for smithy setting DEFAULT_LINUX_VERSION like this:

We should. As I mentioned for cos8, we should change cdt_name to be conda and apply that for cos7 as well. Then we get rid of DEFAULT_LINUX_VERSION.

[beckermr]

Great. Then lgtm on this and we can move the deprecation discussion to smithy.

[h-vetinari]

Planning to merge this in ~24h if there are no further comments.

[jakirkham]

Let's do this during the week (not the weekend) so people are around to fix any issues that come up