build(cuda): Allow DNF fallback for adapter CUDA installs

[bdice]

Summary

Configure dnf with best=False when installing CUDA packages.

Resolves #17714.

[netlify]

✅ Deploy Preview for meta-velox canceled.

Name	Link
🔨 Latest commit	181048f
🔍 Latest deploy log	https://app.netlify.com/projects/meta-velox/deploys/6a2038098190f30008349599

[bdice]

@kgpai It looks like Fedora images are failing to build. This seems related to #17535.

Fedora 42 image rebuild is failing because the pinned tzdata package is no longer available in the current Fedora 42 repositories.

Job logs: https://github.com/facebookincubator/velox/actions/runs/26890954111/job/79316564554?pr=17712

The failure occurs in scripts/docker/fedora.dockerfile while building the Fedora image:

RUN dnf -y install "tzdata-${FEDORA_TZDATA_VERSION}.noarch" || \
      dnf -y downgrade "tzdata-${FEDORA_TZDATA_VERSION}.noarch"

With the current default:

FEDORA_TZDATA_VERSION=2025c-1.fc42

dnf reports:

No match for argument: tzdata-2025c-1.fc42.noarch

I checked current Fedora 42 package availability from quay.io/fedora/fedora:42-x86_64 with dnf repoquery. The visible versions are:

tzdata-2025b-1.fc42.noarch
tzdata-2026b-1.fc42.noarch

tzdata-2025c-1.fc42.noarch is not currently visible from the live Fedora 42 repos, so Docker rebuilds that rely only on those repos cannot reproduce the existing pin.

A proper fix probably needs either a durable source for tzdata-2025c-1.fc42.noarch or an intentional pin change with the timezone fuzzer validation described in PR #17535.

[bdice]

@kgpai I'm not sure what to do with the tzdata issue. Do you think we could import/merge this as a fix for adapters / CUDA image builds, and leave the failed Fedora build for another PR? Happy to hear your thoughts and support you however you want to proceed -- just want to avoid a circular dependency between PRs if we can.

[majetideepak]

@kgpai This seems to be a better fix than pinning a package version, which is always flaky if the OS version is not pinned.
#17522 (comment)