The reason is that composes are expensive. You may see one package and
think: how hard could it be to compose that into a repo and publish it?
Well, composes do a lot more than that. They:
Gather all the packages that are in updates-testing, make sure they
are signed, etc multiplied by 4 different arches ( x86_64, ppc64le,
s390x, aarch64 ). This includes all the debuginfo and src.rpms as well.
Then, for x86_64 it has to resolve multilib stuff. That is, add in 323
bit (i686) packages for compatibility.
Then, once the repos exist, it has to compose some artifacts: We
rebuild cloud images and all the atomic desktops ostree refs (so people
can rebase to updates-testing there) and oci images for all those (which
is what they are moving to).
Then… there’s some tests that take place over the entire repo.
Not just package A, but package A as it interacts with all the rest of
the packages in testing.
That takes a bit less than an hour to do all that (on f44, older
releases are longer since they have more in updates-testing).
Once that is done, the compose can be synced out to the master mirrors.
(a few minutes)
Then mirrormanager needs to update to have the correct metadata
(a few more minutes)
Then, mirrors need to sync that content.
( variable, mirrors sync when they want to on their own schedules, but
they currently expect we update things once a day).
Then, users need to notice that there is new content. Folks with
updates-testing enabled are probibly eager to test, so they might check
once a day or something, but I very much doubt people would check more
often than that.
So, could we push updates-testing more often than once a day?
Perhaps, but I am not sure it would be worthwhile.
I’m not against moving this discussion to the Project Discussion category. I didn’t start it there just because all hashtags used here are not available in that category.
Also, I made a few changes in the koji CLI tool and opened a new pull request with my changes.
With those changes a single line command like the following could be used to upgrade packages by DNF directly from Koji:
urls=$(koji download-build -a local --urls --fail-empty 3071764) && sudo dnf upgrade $urls
It could also be useful for trying any other builds from Koji - updating or installing (with sudo dnf install).
Optionally, when Bodhi is in Pending/Testing mode it can advertise such a command before a usual command like sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-d604bc1848 can work.
Well, it doesn’t handle signing… the bodhi setup tries to figure out
what release it is and download signed copies. Thats important for some
folks, although there may be some weird interactions there trying to
installed signed copies via a url…
Otherwise it seems fine to me, but we will see what koji developers say.
When you run a command like sudo dnf <upgrade or install> <url1> <url2> ... DNF also doesn’t handle signing. In such a case DNF prints a warning like the following:
Warning: skipped OpenPGP checks for 1 package from repository: @commandline
In general my PR just adds to the koji CLI tool the functionality of generating that list of URLs for dnf upgrade or dnf install commands. It doesn’t try to change DNF’s behavior.
