+1

• AGREED: Parallel Installable Debuginfo Change is approved (+7,0,0)
  (nirik, 16:35:27)

+8 with jwbs above.

After a discussion with RelEng ( @ausil ) I would like to ask FESCo to consider removal of this Change from the scope of the Fedora 26 release and/or provide a guidance how to deal with this Change. The rationales for this request are more less obvious from Bug #1340819.

1. The Change is currently not ready to be included in Mass rebuild. We can do the mass rebuild even this is not fully ready, however the Change will then have no (or very low) effect. As such it does not make sense to advertise this as a new feature.
2. The Change is expected to be ready during the next week. Waiting for this Change to be ready means we will need to slip the mass rebuild for at least a week which will consequently slip the whole release.
3. In case this Change will be removed from the Fedora 26 release, we will also need to consider the target release as this Change takes the full effect only if there is mass rebuild. As we do not plan (at the moment) the mass rebuild for the Fedora 27 release, this Change might be rescheduled to Fedora 28 release to get the full mass rebuild.

I agree with the above assessment: this Change is not substantially complete without a mass-rebuild behind it. We should enact the Contingency Plan at this point and push it back to the next release with a scheduled mass-rebuild.

I agree with sgallagh to enact the Contingency Plan. But I think we'd need to schedule a mass rebuild for F27 then, instead of waiting for F28.

OK, I just had a conversation with mjw on IRC and I may be revising my stance, depending on the answers to the following questions:

1. What is the debuginfo-install/upgrade behavior today for a package that has not been rebuilt using parallel-installable debuginfo?
2. What is the debuginfo-install/upgrade behavior today for a package that has been rebuilt using parallel-installable debuginfo?
3. If you have a non-parallel debuginfo package installed and run dnf debuginfo-install foo for a debuginfo that is now parallel, what happens? Is the old one removed?
4. Are the appropriate tools (gdb, etc.) aware of both the old and new locations for debuginfo?
5. Will all future builds automatically generate parallel-installable debuginfo, or the traditional type?

Someone pointed me at this fesco ticket. Please do add Change owners to tickets when Fesco wants to discuss the Change plan. I had planned for this to be installed after the mass rebuild to not disturb it. And because I will be away the next couple of days so couldn't help out if anything would go wrong. Although it would be nice to have a mass rebuild for this change it seemed risky to mix it with a gcc upgrade. If I had known mass-rebuild was a requirement for acceptance of the change I would have worked on some patches earlier.

Note that it doesn't really need a mass rebuild, parallel and non-parallel installable debuginfo packages can co-exist (well, they cannot be parallel installed, but that will have to be supported for upgrades anyway).

Anyway. I will be away for a couple of days (Fosdem!) but when I return I will double checking all upstream patches are backported (at least one is still pending) and then propose an update to the default rpmbuild config macros to enable it. After the fedora rpm maintainers accept that, and we ran some tests, packages will start generating parallel installable debuginfo packages.

If Fesco wants to remove the Change from the marketing materials that is fine by me. The target really is other Fedora hackers that would take advantage of the new debuginfo layout (which is completely backwards compatbile with existing tools). Advertising for end users could be done after all frontend tools have also been updated to provide new functionality taking advantage of being able to have parallel installable debuginfo.

That sounds like it would make sense to keep the Change for F26, introduce it after the mass rebuild so that packages can get slowly rebuilt at their own pace, and then finally do a mass rebuild for F27 to make sure all the packages get updated.

What is the debuginfo-install/upgrade behavior today for a package that has not been rebuilt using parallel-installable debuginfo?
What is the debuginfo-install/upgrade behavior today for a package that has been rebuilt using parallel-installable debuginfo?
If you have a non-parallel debuginfo package installed and run dnf debuginfo-install foo for a debuginfo that is now parallel, what happens? Is the old one removed?
Are the appropriate tools (gdb, etc.) aware of both the old and new locations for debuginfo?

So the answer to these questions are all "the same as it was before". There are changes in the layout of the debuginfo packages but they are backwards compatible. Tools find the build-ids, .debug files and /usr/debug/src files as before. But the files are now installed in non-conflicting way. As long as tools aren't aware different versions of the debuginfo packages can now be installed in parallel they will just install the latest as before.

Will all future builds automatically generate parallel-installable debuginfo, or the traditional type?

parallel-installable debuginfo

See https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo#Detailed_Description for the exact changes to file names/symlinks/.gnu_debuglink. There could always be bugs but tools should just pick up the changed names/symlinks/.gnu_debuglink pointers and work as before. If not we will of course fix the bugs in the tools. For now I haven't found any (yet?).

BTW. There is also a normal bugzilla bug about this Change here: https://bugzilla.redhat.com/show_bug.cgi?id=1340819

I'm OK with approving this (again) in F26, introducing the change after the mass rebuild, and then scheduling another mass rebuild for F27. The only question left in my mind is how to effectively communicate this in the F26 timeframe.

Mass rebuild in this context seems like a non issue. Updating from non-parallel-installable to parallel has to be supported either way. Waiting for another release and another mass rebuild seems like a bad idea.

my thoughts here are that the feature is kinda useless if there is no parallel installable debuginfo packages. there is nothing stopping it being implemented after, but we would want to be clear that for most packages you can not actually use it. I will add that gcc is not quite ready also so we will need to slip for it.