@kkraus14 proposed splitting the cudnn package into a runtime and dev package, where the dev package would depend on cuda-cudart-dev (a requirement of cuDNN headers) while the runtime library would only depend on the other CUDA runtime libraries needed for calling cuDNN functions from its dynamic libraries.
To implement this change, I would suggest a bit of research to see what other conda-forge packages may be depending on the headers being shipped in cudnn, and determine a migration strategy. There may also be some consideration for alignment with how cuDNN is shipped in other CUDA distributions. If no other distribution separates "dev" and "runtime", perhaps this package shouldn't either.
@kkraus14 proposed splitting the
cudnnpackage into a runtime and dev package, where the dev package would depend oncuda-cudart-dev(a requirement of cuDNN headers) while the runtime library would only depend on the other CUDA runtime libraries needed for calling cuDNN functions from its dynamic libraries.Originally posted by @kkraus14 in https://github.com/conda-forge/cudnn-feedstock/issues/56#issuecomment-1522568258
To implement this change, I would suggest a bit of research to see what other conda-forge packages may be depending on the headers being shipped in
cudnn, and determine a migration strategy. There may also be some consideration for alignment with how cuDNN is shipped in other CUDA distributions. If no other distribution separates "dev" and "runtime", perhaps this package shouldn't either.