I'm using --split-debuginfo option to also create the appropriate repository for debuginfo rpms. The problem is that these packages will end up in the same Package folder of the arch directory, instead of a their own Package folder inside of a debug directory. It creates issues when trying to reposync the resulting directory, as the debuginfo packages are not in the expected location. The aim of this issue is to change that behavior or made it configurable.
@mikem Any concerns about making this configurable?
Metadata Update from @tkopecek: - Custom field Size adjusted to None
If there is no problem, I will be very happy to help work towards that. Please give me some pointers or ideas about how you would like it done, and then I can prepare a prototype and iterate with you.
Just to spell this out a little more.
Currently a dist-repo with --split-debuginfo is going to have a layout like this:
[mikem@localhost latest]$ find -name repodata -prune -o \! -name '*.rpm' \! -name [a-z] . ./repo.json ./i386 ./i386/pkglist ./i386/debug ./i386/debug/pkglist ./i386/debug/repodata ./i386/repodata ./i386/kojipkgs ./i386/Packages ./x86_64 ./x86_64/pkglist ./x86_64/debug ./x86_64/debug/pkglist ./x86_64/debug/repodata ./x86_64/repodata ./x86_64/kojipkgs ./x86_64/Packages
The oddity is that while the debug repodata is in a subdirectory (e.g. x86_64/debug), it refers to rpm paths in the main Packages dir. The subrepos created never have their own Packages dir.
Currently the code that manages the split is in the createdistrepo task, but at this point, we're running on the builder and cannot just move files around.
side note - there was a lot of discussion out layout in the original PR -- #914
In general, I am concerned that repos can be laid out in an arbitrary number of ways and we could be opening a Pandora's box in terms of supporting layout variations.
I see how the subrepos referencing paths outside themselves could be a problem for some tools.
Given that dist-repos have worked like this for several years, i don't see this as a big priority and I think we should be very careful about changing this.
I also think it's going to be significantly more work to get right than one might expect from the description.
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/koji/koji/issues/3749
Please continue any further discussion there.