misleading instructions how to use the copr builds

[evgeni]

What happened? What is the problem?

Ohai,

when you have packit build a PR, the users get a link to the dashboard https://dashboard.packit.dev/jobs/copr/:id (e.g. https://dashboard.packit.dev/jobs/copr/1933132) that contains a message how to use the resulting builds, however, those are (possibly) misleading for users not very well versed in copr/dnf.

dnf copr enable {data.copr_owner}/{data.copr_project} without chroot

Right now, the instructions say to call sudo dnf copr enable packit/theforeman-foreman_maintain-936, which on EL8 will try to use the epel-8-x86_64 chroot by default (and epel-9-x86_64 on EL9), but Packit didn't build for those chroots (the linked build is for rhel-8-x86_64) and the user ends up with an error:

Error: It wasn't possible to enable this project.
Repository 'epel-8-x86_64' does not exist in project 'packit/theforeman-foreman_maintain-936'.
Available repositories: 'rhel-9-x86_64', 'rhel-8-x86_64'

Given Packit knows which chroot the build was for, it could add that to the dnf copr invocation, right?

dnf install -y <all packages>

This might be a tad specific to @theforeman packages, but we do have quite a lot sub-packages that get built, but are not needed on a user system (they contain code and dependencies that are needed to build plugins etc).

The instructions on the copr job view tell the user (who might be unaware of our package split!) to dnf install -y all-the-packages-that-were-built which in the best case results in the user installing things they don't need and in the worst case results in dependency errors from dnf as we don't ship all packages required for building in our main repos.

It would be cool if the wording would point out that this might not what you need, or allow projects to override this messaging in their packit.yml

What did you expect to happen?

No response

Example URL(s)

https://dashboard.packit.dev/jobs/copr/1933132

Steps to reproduce

1. tell users "take the packit build from <PR link>"
2. see them following the instructions literally

Workaround

• There is an existing workaround that can be used until this issue is fixed.

Participation

• I am willing to submit a pull request for this issue. (Packit team is happy to help!)

[Venefilyn]

Yeah I agree we can improve this, since dnf copr enable supports chroot that seems super easy to fix

[evgeni]

@Venefilyn #471 fixes the first problem (chroot) but not the second (installs all packages). Should I open a new issue with just the second problem description?

[lbarcziova]

@evgeni good point, let's track the second one in here as well.

[Venefilyn]

Good point, missed that when I fixed the first part.

@evgeni for not installing all packages option, do you have an example of a Copr build that includes packages that shouldn't all be installed? Can they be installed individually or are there some that are not needed? (if so what is the build used for)

Just trying to gather some info so I can see about improving the UI

[evgeni]

Sure!

Two good examples:

• https://dashboard.packit.dev/jobs/copr/1940048 asking to dnf install -y foreman-service-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-postgresql-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-cli-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-telemetry-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-dynflow-sidekiq-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-debug-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-build-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-libvirt-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-redis-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-plugin-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-openstack-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-vmware-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-journald-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-pcp-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-console-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-ovirt-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-assets-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch foreman-ec2-3.12.0-0.20241014082159886203.pr10348.2.g891b77e68.el9.noarch
• https://dashboard.packit.dev/jobs/copr/1934779 asking to dnf install -y rubygem-katello-doc-4.15.0-0.1.pre.master.20241010172748411037.pr11179.5523.gdfeebfa794.el9.noarch rubygem-katello-assets-4.15.0-0.1.pre.master.20241010172748411037.pr11179.5523.gdfeebfa794.el9.noarch rubygem-katello-4.15.0-0.1.pre.master.20241010172748411037.pr11179.5523.gdfeebfa794.el9.noarch

To tell you what's wrong with those lists of packages, I first gotta explain you our deployment architecture, so take a hot chocolate (or whatever else you prefer and sit back).

Foreman is a Ruby on Rails application that relies on Webpack (and thus NPM/NodeJS) for the frontend.
Katello is a plugin to Foreman (technically, a Rails Engine, forget this fact quickly again).

When building Foreman, we need to install a lot NPM packages, but the built result doesn't require those to run on the users system.
When building Katello, we also need a lot NPM packages, and additionally some artifacts from the Foreman build that we hide in the foreman-assets package. Again, this is only build-time, end users do not need any of the NPM/NodeJS stuff at all.
We also have other plugins that might require Katello to work, and to build these you need NodeJS, NPM, foreman-assets and… rubygem-katello-assets

This means that we have these two layers of -assets packages, that are only useful for building. They also come with a ton of NPM/NodeJS deps, so when you try to install them on your normal Foreman server, you either lose a couple GB storage or get ugly errors from DNF because you don't have the right NodeJS module or maybe don't even have the right repos enabled which ship that stuff.

Another thing (and that's why also linked to a foreman build above) is that the Foreman package has many sub-packages, for supporting a modular setup where not all features have to be enabled. Like you can drop VMware or OpenStack support, or run it without the Redis cache, etc etc. Installing any of these packages on a system that doesn't have that feature enabled would enable the feature -- something a user might not want to do.

I think the cheapest fix for this issue would be to modify the message to be like this:

• If there is exactly one package in the build result, display dnf install as before
• If there are multiple packages, make the message something like "You can now install individual packages from this build using dnf install <package_name>. Alternatively, you can use dnf upgrade to upgrade already installed packages to the ones from this build. The full list of built packages is: the list"

[Venefilyn]

What about something like this? Would mean we get a list of the packages. Could also instead of a list use a table with a copy-all in the header or something

[evgeni]

Yeah, that certainly also works!

Thanks!

[lbarcziova]

@Venefilyn thanks for the suggestion, I like it! Just as you write, we should still leave a way to copy the whole sudo dnf install <all-packages> command

[Venefilyn]

Both should be fixed now @evgeni 🙏

Let me know how it looks now in staging. The update isn't in production yet

https://dashboard.stg.packit.dev/jobs/copr/67082

[evgeni]

Thanks! Looks good to me