# Kubernetes yum configuration for all versions **URL:** \ **Category:** General Discussions\ **Created:** [April 30, 2024, 12:37pm UTC](https://discuss.kubernetes.io/t/kubernetes-yum-configuration-for-all-versions/28082 "2024-04-30T12:37:52Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![J17359](https://avatars.discourse-cdn.com/v4/letter/j/22d042/32.png) [@J17359](https://discuss.kubernetes.io/u/J17359)\ **Post date:** [April 30, 2024, 12:37pm UTC](https://discuss.kubernetes.io/t/kubernetes-yum-configuration-for-all-versions/28082/1 "2024-04-30T12:37:52Z")
Hello Kubernetes Forums! I have recently migrated my yum/dnf configuration in order to access the `kubectl` package following the instructions documented [here](https://kubernetes.io/blog/2023/08/15/pkgs-k8s-io-introduction/#how-to-migrate-rpm). We were using the legacy repos before and are successfully using the new repos today. My question is, is there a way to configure the yum/dnf `baseurl` such that we’d have access to all future versions and could automatically roll to those new versions without having to change our yum/dnf configuration? Today my yum baseurl (as instructed in the above link) looks like `baseurl=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/`. If I want to move to 1.29, for instance, I’d have to change my yum repo file on all systems I support to be `baseurl=https://pkgs.k8s.io/core:/stable:/v1.29/rpm/`. That is easy but then prevents anyone from using 1.28. Is there a way that I can do something like `baseurl=https://pkgs.k8s.io/core:/stable:/all/rpm/` to gain access to **all** version of the Kubernetes packages such that I can use yum to pick and choose the version I want dynamically? (e.g. `yum install kubectl-1.28`) Thanks for your time! ### Cluster information: Kubernetes version: 1.28 Cloud being used: bare-metal Installation method: yum Host OS: AlmaLinux 8 CNI and version: ? CRI and version: ? ---
**Author:** ![mrbobbytables](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/mrbobbytables/32/7_2.png) [@mrbobbytables](https://discuss.kubernetes.io/u/mrbobbytables)\ **Post date:** [April 30, 2024, 12:52pm UTC](https://discuss.kubernetes.io/t/kubernetes-yum-configuration-for-all-versions/28082/2 "2024-04-30T12:52:00Z")
No, that was an intentional change. For more information on why, please see this blog: > **[pkgs.k8s.io: Introducing Kubernetes Community-Owned Package Repositories](https://kubernetes.io/blog/2023/08/15/pkgs-k8s-io-introduction/#why-are-we-introducing-new-package-repositories)** > > On behalf of Kubernetes SIG Release, I am very excited to introduce the Kubernetes community-owned software repositories for Debian and RPM packages: pkgs.k8s.io! The new package repositories are replacement for the Google-hosted package repositories... ---
**Author:** ![J17359](https://avatars.discourse-cdn.com/v4/letter/j/22d042/32.png) [@J17359](https://discuss.kubernetes.io/u/J17359)\ **Post date:** [April 30, 2024, 2:05pm UTC](https://discuss.kubernetes.io/t/kubernetes-yum-configuration-for-all-versions/28082/3 "2024-04-30T14:05:25Z")
Thanks @mrbobbytables ! I read that blog but must have missed the reasoning before. For anyone reading this thread, reasoning seems to be (correct me if I’m wrong): > Another problem is that we only have a single package repository. Because of this, we were not able to publish packages for prerelease versions (alpha, beta, and rc). This made testing Kubernetes prereleases harder for anyone who is interested to do so. ---
**Author:** ![mrbobbytables](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/mrbobbytables/32/7_2.png) [@mrbobbytables](https://discuss.kubernetes.io/u/mrbobbytables)\ **Post date:** [April 30, 2024, 2:20pm UTC](https://discuss.kubernetes.io/t/kubernetes-yum-configuration-for-all-versions/28082/4 "2024-04-30T14:20:55Z")
No prob! - One other bit along with what you posted is it made it difficult to manage other dependencies associated with the release (e.g. cri-tools). Moving to the one version schema ensures there are no conflicts there.