Can you describe the use case here a bit more?

I have a build failure and need debugging information to debug it, which in turn requires debuginfo packages. Previously, I probably needed to install perhaps three or four debuginfo packages after locating the respective builds on Koji. Now the number is twice that or more, and it's becoming cumbersome.

Waiting for a successful compose (which has a debuginfo repository) is not always an option, particularly if the build I'm trying to fix is needed to un-break the compose.

From dgregor: didn't know about this ticket but can get into the road map.

Did this ever get on the roadmap?

Hi. This has not made it onto the road map yet, but I've gone and tagged it for 1.19. That isn't a commitment, but we'll be doing 1.19 planning shortly and will make sure to take a look at this. Does this continue to be a pain point?

Fedora is discussing whether to stop producing i686 composes:

• https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/T5ZV5WCJ7U7BFQXC6RTNG3AIHXOORYOC/

The x86_64 compose is not suitable for use with mock, so until Koji provides a repository with debuginfo packages, we wouldn't have a way to easily install debuginfo packages with mock anymore.

I wonder, how to handle this. Creating debuginfo repos for all buildroots seems to be a bit overkill. Setting flag on build tag, that it should create also debuginfo is more usable for relengs, but not much for devels. If they need debuginfo packages, they would need to reach to relengs to enable it and regen repo.

Maybe other way around? Create debuginfo repo by default and let flag to disable it?

I would appreciate if at least debuginfo for kernel was available by default.

We're looking to wrap up 1.19 development shortly and given that there are still unknowns with this issue, I'm pushing it out to 1.20. We can keep the discussion going though to better understand the requirements and a design that will meet those while still being performant.

There is an option to run regen-repo with --debuginfo option. Nowadays, not only admin can do that, but anybody with 'repo' can trigger it. Caveat is, that it will 'pollute' regular buildroot. To avoid it, it makes sense to create sidetag and run regen-repo --debuginfo on that. Such sidetag can be used for debugging and then deleted.

Does it make sense, or do you find it too clumsy?

Won't the debuginfo packages go away again if the repository is regenerated without the flag? That seems potentially confusing.

Yes, but that was my reason to use sidetag for that - in that case you'll have full control about that repo druing the debugging phase. You shouldn't ever run it against "production" buildroot. I still don't like the idea, that debuginfo repos are generated every time regen-repo is run. On demand variant looks more usable to me.

@mikem @dgregor ?

So, my proposed solution:
in 1.21
- merge sidetag plugin into koji, so we can do it for more internally.
- allow extra info for sidetag stating, that its repos should be created with debuginfo content
- use such sidetags for debugging (it would mean running koji add-sidetag f32-build --debuginfos, then you should have an usable repo and you can destroy it after that with koji remove-sidetag xyz

You can do it similarly now (but you need 'repo' or 'admin' permission to trigger that altered createrepo), so there is a ~workaround for now.

Does it seems usable for everyone?

Merging sidetag plugin: https://pagure.io/sidetag-koji-plugin/issue/12

PR #1990

Commit ee615ed0 fixes this issue

Commit 2a621b33 fixes this issue

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/540

Please continue any further discussion there.