rpmspec does not expect debuginfo rpm for a subpackage

[fepitre]

I've attached here https://gist.github.com/fepitre/de06639902f5da5f8614723da76a71c4#file-qubes-qrexec-spec a spec file for which I'm trying to predict resulting RPM files.

I've attempted to query with either --builtrpms or --rpms (default) but the resulting RPMs:

$ rpmspec -q --qf '%{name}-%{version}-%{release}.%{arch}.rpm\n' qubes-qrexec.spec 
qubes-core-qrexec-4.1.16-1.fc35.x86_64.rpm
qubes-core-qrexec-libs-4.1.16-1.fc35.x86_64.rpm
qubes-core-qrexec-devel-4.1.16-1.fc35.x86_64.rpm
qubes-core-qrexec-debuginfo-4.1.16-1.fc35.x86_64.rpm
qubes-core-qrexec-debugsource-4.1.16-1.fc35.x86_64.rpm

differs from what Mock produces:

DEBUG: Wrote: /builddir/build/RPMS/qubes-core-qrexec-devel-4.1.16-1.fc35.x86_64.rpm
DEBUG: Wrote: /builddir/build/RPMS/qubes-core-qrexec-libs-4.1.16-1.fc35.x86_64.rpm
DEBUG: Wrote: /builddir/build/RPMS/qubes-core-qrexec-debugsource-4.1.16-1.fc35.x86_64.rpm
DEBUG: Wrote: /builddir/build/RPMS/qubes-core-qrexec-libs-debuginfo-4.1.16-1.fc35.x86_64.rpm
DEBUG: Wrote: /builddir/build/RPMS/qubes-core-qrexec-4.1.16-1.fc35.x86_64.rpm

In this case, debuginfo package is for the subpackage libs. I admit it is impossible to predict if a debuginfo package will exist without building it but, should debuginfo/debugsource built RPMs be expected also for subpackages? For example, in this case --builtrpms would produce:

qubes-core-qrexec-4.1.16-1.fc35.x86_64.rpm
qubes-core-qrexec-libs-4.1.16-1.fc35.x86_64.rpm
qubes-core-qrexec-libs-debuginfo-4.1.16-1.fc35.x86_64.rpm <- new one
qubes-core-qrexec-devel-4.1.16-1.fc35.x86_64.rpm
qubes-core-qrexec-debuginfo-4.1.16-1.fc35.x86_64.rpm
qubes-core-qrexec-debugsource-4.1.16-1.fc35.x86_64.rpm

[pmatilai]

This is just an artifact of the implementation - the top level debug packages are created by a different (much older) mechanism and thus they always exist at parse time already, whereas the sub-package debug packages are created inside the files processing which doesn't happen during spec parse.

There's no easy fix for that I'm afraid.

[DemiMarie]

There's no easy fix for that I'm afraid.

Would it require a major refactoring?

[ffesti]

No, refactoring does not help here. This is a general problem: Those debuginfo packages' existence depends on the content of their associated sub package. The content does not exist until those packages are built. But the purpose of the rpmspec command is to get the list of package before/without building the package.

[fepitre]

No, refactoring does not help here. This is a general problem: Those debuginfo packages' existence depends on the content of their associated sub package. The content does not exist until those packages are built. But the purpose of the rpmspec command is to get the list of package before/without building the package.

I agree. The only workaround I've found for now is to add -debuginfo/-debugsource for the package and all its subpackages (except devel) to have list off all possible packages before build.

[ffesti]

In the end we have to accept we can't get a correct list and we have to decide whether the list errs on to many or too little packages or both. As we are currently considering dynamic sub packages we will end up with too little no matter what. So I am hesitant to opt for too many here.

[fepitre]

@ffesti if you want a bit of context for why I've reached this, I'm currently creating a build system that runs actual build inside a cage (either a container or an ephemeral VM) and I only copy-back expected RPMs. Having too many allows to skip if it does not exist. On the other hand, having unexpected RPMs raise a build failure. The idea is to not inject unexpected RPMs inside a repository where all is done automatically.

[pmatilai]

Perhaps the sanest behavior we can do is only generate debuginfo packages on an actual build, and never any on rpmspec query. That way it's at least somehow consistent with itself.

As for "unexpected" packages, debuginfo are consistently named and thus easily filtered. I wouldn't build too much structure around the notion of unexpected packages as Dynamic Spec Generation will change that quite fundamentally.

[pmatilai]

This is actually quite closely related to #2204 which we now have to fix.