FWIW, while it is possible, you shouldn't have debugsource subpackages disabled when you have debuginfo subpackages, because then the sources will be stuffed into the main debuginfo package.

I suggest actually having both enabled, but at the minimum, I'd like to see the debugsource packages enabled in Fedora.

@ausil We would like your input on this one. We are not sure how this can be achieved.

I didn't get any feedback on my request for testers.
https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.org/message/ITJHJTUO2WFEAYIHANSM6AMAB5SIFASI/
I'll ping next week to see if I can get some volunteers to enable these options for their packages.
But for now lets keep these disabled by default since they haven't seen enough testing yet.

It might be helpful for review to enable them for some of my own packages. But I'll do that after the mass rebuild so it doesn't interfere with that.

@mjw

The only reason I haven't enabled it myself is that I wasn't sure if @ausil or @mohanboddu have confirmed that both *-debugsource and *-debuginfo packages will be placed in the debug/ repo as intended.

This feature is intended to be switched on, but I'm waiting to have confirmation about this specific thing, as I don't want debug packages bleeding into the regular repositories. I have no idea how the repo filtering even works.

AFAICS pungi does not know about -debugsource:

https://pagure.io/pungi/blob/master/f/pungi/gather.py#_69

The check should probably be if po.endswith("-debuginfo") or po.endswith("-debugsource") .

The tool currently used for update repos (mash) does not seem to know -debugsource as well:

https://pagure.io/mash/blob/master/f/mash/__init__.py#_379

I am pretty sure that currently both tools need to be changed but it might be that we will not use mash for F27 anymore. I do not know the exact roadmap here to be honest.

Do you intend to make the changes default prior to the mass rebuild for Fedora 27 so packages all have it enabled? https://fedoraproject.org/wiki/Changes/RPM-4.14 seems to indate its expected to be the default

pungi, mash, koji will all need updating on the definition of what is a debug package. possibly other tools in QA will need updating also, @tflink @adamwill @kparal any input on QA impacts of having debugsource packages for debug data on top of debuginfo?

Do you intend to make the changes default prior to the mass rebuild for Fedora 27 so packages all have it enabled? https://fedoraproject.org/wiki/Changes/RPM-4.14 seems to indate its expected to be the default

It's expected to be the default, but we haven't flipped the switch due to not wanting "surprises" from the releng tooling.

I'd like to be able to flip the switch before the mass rebuild, so that we can get maximum exposure and usefulness.

Do you intend to make the changes default prior to the mass rebuild for Fedora 27 so packages all have it enabled?

No. At first it will be optional for packagers to opt in by defining the two macros in their spec file.

Only after we get feedback from packagers and are sure that the releng tools handle -debugsource packages correctly can we consider flipping those on by default.

Also there are a couple of packages (notably the kernel, glibc and gcc) that already have split source and/or subpackage-debuginfo packages. We will first need to make sure they can be switched to use the standard macros or have them explicitly opt-out before making this the default.

But it is unclear when the mass rebuild is going to be (I assumed it would already have happened by now). If there will be some time till the mass rebuild is going to be done then it might be possible to complete the above and flip the macros on by default.

Sidenote I will be on vacation and won't be able to help with setting this as default between August 9 and August 28.

Note that both %_debugsource_packages and %_debuginfo_subpackages have been enabled in rawhide by default now since rpm-4.13.0.1-37 so now packages will have to explicitly opt-out instead.
Sorry for the bad coordination.

pungi, mash, koji will all need updating on the definition of what is a debug package. possibly other tools in QA will need updating also, @tflink @adamwill @kparal any input on QA impacts of having debugsource packages for debug data on top of debuginfo?

From Taskotron POV, some tasks (e.g. abicheck) use debuginfo packages and we download them from koji simply by koji list-rpms NVR | grep debuginfo (not an actual command, we use koji API). We can extend our tools to filter debugsource packages as well, should not be difficult.

However, I'm not clear what the difference is between a .src.rpm package (from fedora-source repo) and -debugsource.rpm package (from fedora-debuginfo repo, I assume). The wiki page doesn't explain it either. Can someone clarify? Thanks.

From Taskotron POV, some tasks (e.g. abicheck) use debuginfo packages and we download them from koji simply by koji list-rpms NVR | grep debuginfo (not an actual command, we use koji API). We can extend our tools to filter debugsource packages as well, should not be difficult.

BTW. Maybe you don't even need the sources. Depending on how abicheck works. If you need to inspect include files you might need the sources. But most/all of the ABI can extracted from just the DWARF information in the .debug files.

However, I'm not clear what the difference is between a .src.rpm package (from fedora-source repo) and -debugsource.rpm package (from fedora-debuginfo repo, I assume). The wiki page doesn't explain it either. Can someone clarify? Thanks.

Good question. That wasn't properly explained indeed. The src.rpm is the source from which the binaries are build. This however might not be in a convenient form when matching debug info to source code. It will most likely need to be unpacked, preprocessed and it doesn't contain generated files for example. The debug sources are the actual/final source code corresponding to the binary. It contains only those files actually used to create the binaries (and referenced from the debug files). All conveniently in one place under /usr/debug/src/<package-nvra>/

Suppose you have a situation where a .spec file creates a main package and several sub-packages, but only some of the sub-packages will contain debug info. The packagers now (f28+) must add

%undefine _debugsource_packages

in order to avoid the empty debug list error produced by some of the sub-packages and thus force all debug info into one package. Would it not be better to be able to enable/disable debug info generation on a per-package basis within the spec file?

Seems like it's a binary choice now, all or nothing.

@pkfed it most likely means that your package doesn't follow guidelines.. But please file bug against RPM and we can try to help you... (releng can't do anything here)

Suppose you have a situation where a .spec file creates a main package and several sub-packages, but only some of the sub-packages will contain debug info. The packagers now (f28+) must add
%undefine _debugsource_packages

in order to avoid the empty debug list error produced by some of the sub-packages and thus force all debug info into one package. Would it not be better to be able to enable/disable debug info generation on a per-package basis within the spec file?
Seems like it's a binary choice now, all or nothing.

Could you file a bug for this? I might not completely understand your setup. But in general packages that don't contain binaries/debuginfo/source should just work fine. If there is a subpackage that does get debuginfo subpackage, but doesn't contain any corresponding source their is most likely a packaging error. If you can file a bug with a reproducer then we might be able to figure out why it is happening.

I was able to take some time to revisit this problem and It turns out that the package's build system was silently filtering the '-g' cflag, thus producing empty debugsourcefiles.list files and causing the fatal error. Releases f26 and f27 don't produce the error, so when it popped up in f28, I thought something had broken in rawhide. All good here now.

AFAICS pungi does not know about -debugsource:
https://pagure.io/pungi/blob/master/f/pungi/gather.py#_69
The check should probably be if po.endswith("-debuginfo") or po.endswith("-debugsource") .
The tool currently used for update repos (mash) does not seem to know -debugsource as well:
https://pagure.io/mash/blob/master/f/mash/__init__.py#_379
I am pretty sure that currently both tools need to be changed but it might be that we will not use mash for F27 anymore. I do not know the exact roadmap here to be honest.

Does anybody know the roadmap? At the moment it looks like -debugsource is still not recognized as belonging next to -debuginfo in the repos. Causing -debugsource packages to show up in the main repo instread of the debug repo.

It's fixed in pungi. It should be fixed in the next rawhide compose (whenever people stop breaking things so we get one).

f27 will get fixed after beta is out and we are out of beta freeze.

Hopefully bodhi will be switched to using pungi instead of mash after f27 beta freeze and before f27 final release, which means it would be fixed there after that happens.

Bodhi calling pungi work is done and -debugsource packages are now along with -debuginfo packages.