Using dnf to install, update, remove, and manage software packages on Linux | Into the Terminal 128

[@behappy3253]

Thank so much for your help

[@boubou40]

I often use the dnf module command that enables me to switch to different versions of software like php without removing packages (on module-aware packages)

[@RedHatEnterpriseLinux]

@@boubou40 after being all-in on modularity with RHEL8, we’ve been pulling away from it since. I’ve been told by engineering to expect that modular packages will not be included with RHEL 10.

[@markainge243]

Thanks for the show, I have a question around the 'download only' option you mention. Does this mean that when you finally run a 'dnf update', this just runs for the previously downloaded files OR all files that are covered by the 'update' at that time including new updates?

[@scottmcbrien6535]

In theory it would run off of both downloaded content *and* any newly released content since the -downloadonly cache was built. Thats why I recommend building the cache a couple days before the planned update because you can get all, or at least the large bulk, of the updates staged in the local cache. This may also depend on whether you use Red Hat Satellite or not. With Satellite, you control what updates are made available to boxes, so if you’ve not added any new updates to the content view, then the -downloadonly cache would match what is available to the system.

[@DavidLange1492]

We need to have multiple versions of application module software. Seems difficult to do with module system and documentation lacks that information.

[@RedHatEnterpriseLinux]

@@DavidLange1492 there are a couple of packages, like the pythons or gcc-toolsets designed to be installable in parallel, but generally when it comes to modules you can choose any one version that you want. Like the Highlander, there can be only one. I’d suggest looking into containers instead, essentially offering a container with whatever version you need, where each different container could offer a different version of a language.

[@DavidLange1492]

@@RedHatEnterpriseLinux That's what I believed from the documentation. Unfortunately, developers request multiple versions to be usable at all times. The situation sysadmins have to face in the field.

[@scottmcbrien6535]

@@DavidLange1492 I mean I hear you, but just because everyone wants ponies, doesn't mean everyone gets a pony. They're impractical, not unlike installing every runtime in parallel on a machine. Containers are the solution to this problem because it allows for each individual runtime version to bring all it's own dependencies and weirdnesses without affecting everything else on the system. Though if developers aren't willing to create their own containers, perhaps you could do it and make it available on all the needed systems via a local repository? You could even have a central repository so that individual devs could pull them to a system of their choosing. Red Hat does this to some extent with a variety of run-time UBI (Universal Base Images). Though they are built to generally include all the things, so, for example, the python one is pretty large. One could start with a UBI standard and use the included DNF to pull in whatever specfic runtimes they wanted though and you'd have a pretty easy method for building and maintaining a catalog of containers unique to your organization.