host microarch level leaks into run requirements

[jjhelmus]

Comment:

Following the instructions for use of this package in the knowledge base results in packages that also depends on the microarchitecture level of the host machine if the recipe includes a requirements/host section.

For example:

meta.yaml

package:
  name: sample
  version: "1.0.0"


requirements:
  build:
    - x86_64-microarch-level {{ microarch_level }}  # [unix and x86_64]
    - {{ compiler('c') }}
  host:
    - ca-certificates

conda_build_config.yaml

microarch_level:  # [unix and x86_64]
  - 1  # [unix and x86_64]
  - 3  # [unix and x86_64]
  - 4  # [unix and x86_64]

Building this on host with a Zen4 cpu:

# conda info | grep archspec
       virtual packages : __archspec=1=zen4
# conda build .
...
# conda search --info -c local sample --override-channels
Loading channels: done
sample 1.0.0 h00d5617_0
-----------------------
file name   : sample-1.0.0-h00d5617_0.tar.bz2
name        : sample
version     : 1.0.0
build       : h00d5617_0
build number: 0
size        : 3 KB
subdir      : linux-64
url         : file:///opt/conda/conda-bld/linux-64/sample-1.0.0-h00d5617_0.tar.bz2
md5         : c034688ab7ce82943fe6ecabac19d488
timestamp   : 2024-06-04 21:12:10 UTC
dependencies:
  - _x86_64-microarch-level >=3
  - _x86_64-microarch-level >=4
  - libgcc-ng >=13


sample 1.0.0 h9becff6_0
-----------------------
file name   : sample-1.0.0-h9becff6_0.tar.bz2
name        : sample
version     : 1.0.0
build       : h9becff6_0
build number: 0
size        : 3 KB
subdir      : linux-64
url         : file:///opt/conda/conda-bld/linux-64/sample-1.0.0-h9becff6_0.tar.bz2
md5         : 66bdae327a171000c4a169c3f78bbbcb
timestamp   : 2024-06-04 21:12:20 UTC
dependencies:
  - _x86_64-microarch-level >=1
  - _x86_64-microarch-level >=4
  - libgcc-ng >=13


sample 1.0.0 hafcd524_0
-----------------------
file name   : sample-1.0.0-hafcd524_0.tar.bz2
name        : sample
version     : 1.0.0
build       : hafcd524_0
build number: 0
size        : 3 KB
subdir      : linux-64
url         : file:///opt/conda/conda-bld/linux-64/sample-1.0.0-hafcd524_0.tar.bz2
md5         : 697ddd2a00308ebf314400beb6484876
timestamp   : 2024-06-04 21:12:15 UTC
dependencies:
  - _x86_64-microarch-level >=4
  - libgcc-ng >=13

Notice that all of the packages have a dependency on the host microarch-level (>=4). This is a result of the strong run_export in the _x86_64-microarch-level package being applied from the host section after it is added as a requirement by the strong run_export from the x86_64-microarch-level package in the build section. Strong run_exports from the build section do apply transitively in the host section (or at least have for the last ~7 years).

Rendering microarch_level 1 gives a good look at what is happening:

e# conda render .
--------------
Hash contents:
--------------
{'c_compiler': 'gcc', 'microarch_level': '1', 'target_platform': 'linux-64'}
----------
meta.yaml:
----------
package:
  name: sample
  version: 1.0.0
build: {}
requirements:
  build:
    - libsanitizer 13.2.0 h6ddb7a1_7
    - gcc_impl_linux-64 13.2.0 h9eb54c0_7
    - gcc_linux-64 13.2.0 h1ed452b_3
    - libgcc-ng 13.2.0 h77fa898_7
    - x86_64-microarch-level 1 1_k10
    - ld_impl_linux-64 2.40 hf3520f5_2
    - sysroot_linux-64 2.12 he073ed8_17
    - libstdcxx-ng 13.2.0 hc0a3c3a_7
    - libgomp 13.2.0 h77fa898_7
    - binutils_linux-64 2.40 hdade7a5_3
    - binutils_impl_linux-64 2.40 ha1999f0_2
    - _openmp_mutex 4.5 2_gnu
    - _libgcc_mutex 0.1 conda_forge
    - kernel-headers_linux-64 2.6.32 he073ed8_17
    - libgcc-devel_linux-64 13.2.0 hceb6213_107
  host:
    - _x86_64-microarch-level 4 1_zen4
    - ca-certificates 2024.6.2 hbcca054_0
    - _libgcc_mutex 0.1 conda_forge
    - libgomp 13.2.0 h77fa898_7
    - _openmp_mutex 4.5 2_gnu
    - libgcc-ng 13.2.0 h77fa898_7
  run:
    - _x86_64-microarch-level >=1
    - _x86_64-microarch-level >=4
    - libgcc-ng >=13
about: {}
extra:
  copy_test_source_files: true
  final: true

First the strong run_export on _x86_64-microarch-level >=1 is added to the host and run section from x86_64-microarch-level 1 in the build section.

Then the host section is evaluated. The solver selects the _x86_64-microarch-level=4=1_zen4 package and applies the _x86_64-microarch-level >=4 strong run_export to the run section.

I see a few option:

• This is bug in conda-build, transitive run_exports should not propagate from the build section to the host section. That said this bug has existed for considerable time and may be a "feature" as this point.
• Remove the all run_exports from the _x86_64-microarch-level package. Rely on the x86_64-microarch-level to add them to the run section.
• Introduce a new package with no run_exports that the x86_64-microarch-level package specifies as a strong run_export. This package would have a run dependency on the appropriate _x86_64-microarch-level package.

cf #5 which touches on some of these points.

[isuruf]

Remove the all run_exports from the _x86_64-microarch-level package. Rely on the x86_64-microarch-level to add them to the run section.

Sounds good to me.

[jjhelmus]

Remove the all run_exports from the _x86_64-microarch-level package. Rely on the x86_64-microarch-level to add them to the run section.

Sounds good to me.

I agree. I removed the run export in #7. Are there concerns about the existing packages (build numbers 0 and 1 ) being selected during a build and including the run_export? If so should these packages be moved off the main label?