The initial motivation for this feature was so that it could be used by pungi. What does the pungi use case expect as far as debuginfo?

I think this change may no longer be needed. My understanding is that the separate debuginfo/source/binary repos would be needed if the dist repos became a direct replacement for mash. With bodhi switching from mash to pungi, nothing will be using mash anymore and pungi is capable of using the dist repos as-is. Can anyone confirm this?

ping @lsedlar @bowlofeggs @ausil

Well, dist-repos still need to be able to handle this. The whole point of them is to incorporate the functionality of mash in the right place.

debug(info|source) subpackages should go into debug/ subrepo...

@ngompa can you expand on the use case? If we are using pungi instead of mash, and pungi understands the existing dist repos structure, what would be the need for the change?

@dgregor the use case for fixing this is to able pungi to use dist-repos as an otion for creating repos. allowing us to scale out repo creation by farming tasks to multiple machines rather than having them all on a single machines. Which is a step we want to take things.

I can confirm that Bodhi is switching to use Pungi to make its repos, so as long as Pungi doesn't need this I assume things are fine. It sounds like @ausil is saying that Pungi needs it though.

Pungi is creating two kinds of repos. The ones that are shipped as a final result of the compose need to be separated by binary/debug/source packages, so dist-repos in current form can not be used for this.

The other usecase is creating a repo with packages from a koji tag: Pungi finds paths to signed copies of the packages and then creates one repo per binary arch. In this case the repo contains all kinds of packages. This repo is only used for solving dependencies, it's never shipped anywhere. For this case dist-repos might be useful even in the current state. The depsolving code can work with multiple repos, so having the repos split as requested here would not be a problem.

I am close to a implementation on this, but it is not quite there yet and pretty invasive to the code (which was really not written with any sort of split layout in mind).

So this isn't going to make 1.15, but I will make it a priority for 1.16. It should land early in the cycle to it can get more testing before that release.

Commit 18600b2 fixes this issue