https://bugzilla.redhat.com/show_bug.cgi?id=1212124 --- Comment #4 from Alexander Ploumistos <alex.ploumistos@xxxxxxxxx> --- (In reply to Jan Chaloupka from comment #2) > Debuginfo packages are provided only for subpackages providing binaries. As > this package provides only source codes there is nothing to debug and thus > debuginfo is empty I did a little more digging into Go this morning and I think I understand how this works now. > What line? This package has no %files section, only %files devel. Oops... I could have sworn at the time that I was seeing a %files and a %files devel section. Perhaps I should refrain from reviews in the wee hours... > As the main purpose of almost all golang packages is "being buildtime > dependency", there is usually only devel subpackage. And as there is a high > change a golang project is going to be used in other golang projects, each > spec file provides at least one devel subpackage. You can see devel > subpackage as static subpackage of C project. However, as there is nothing > as shared library in golang we ship all golang source codes. Once a golang > project is built (go build) we have binaries as well. Binaries and source > codes are separeted. Check etcd or kubernetes packages for example. So a library for a compiled language that is only used during buildtime warrants just a -devel package. Thanks, I was under the impression that we couldn't have standalone devel packages. > I can try to detect it via git tags but I does not have to be 1:1 mapping > (the latest tag does not has to be the latest release :(). I think that the requirement to package the latest upstream version refers to normal releases and not snapshots, I guess that's what you mean too. Thank you very much for taking the time to respond and for all the information. I wish you get a formal review pretty soon. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review