Hi Fabio,

thank you for staying with us in the Go packaging world and for sharing any difficulty or problem you encounter with. I created github repository [1] where you can report all issues wrt. macros used in Go packaging. We are currently in a process of iterating over all the macros. Though, I am finally confident we are going in the right direction. Providing set of macros we can share with goal to simplify and minimize package maintenance. I did not want to make the new macros publicly aware until me and Nicolas are sure they work in both our environments.
Yet, it's great to see they are already getting accepted.

[1] https://github.com/gofed/go-macros

Let me answer all question as best as I can as well.

On 02/27/2018 05:21 PM, Nicolas Mailhot wrote:
Le 2018-02-27 15:49, Fabio Valentini a écrit :

I'll answer in more detail since I have a little more time now

2) Additionally, I wasn't able to figure out why I have to set both
"%gobaseipath" and "%provider_prefix".

That's one of the changes Jan made I don't understand either. It's looks like an attempt to reintroduce old Go packaging conventions, but as they overlap with the new ones (but are not sufficient to replace them), no good can come out of it.

The %provider_prefix and %gobaseipath are already gone.
For the %provider_prefix I needed to get more familiar with the forge macros Nicolas introduced so I can decide if it is sufficient replacement. And it is. The %gobaseipath macro had the same meaning as %goipath. I wanted to stress it must contain the base import path so packagers do not accidentally set it to invalid value. I still believe we should stress that information. However, it can be mentioned in the documentation. If not explicitly stressed in the macro names it can be later checked by a Go specific spec linter.

3) The %gosource macro doesn't work correctly (at least for github
sources). The "/archive/" part between the "import path" and
"%{commit}" or "%{version}" is missing as far as I can see.

The original code is in redhat-rpm-config in devel only, Jan tried to rewrite it so it works on stable too, and the result is what you saw. I think the simplest solution is just to revert this part of the rewrite and ask the redhat-rpm-config maintainers to push the original working code to stable redhat-rpm-config (they've already indicated they will push it to stable as soon as we give them the green light, so the whole rewrite thing to avoid doing what was already planed is a misunderstanding)

Thanks Nicolas for providing the forge macros. We no longer have to deal with the gosource (and other macros) manipulation in the context of the Go packaging. The project repository sources processing has been moved under general solution. If anything goes wrong with the forged macros, please open a bz bug for redhat-rpm-config component (CC'ing Nicolas as well).

4) The downloaded tarball has potentially ambiguous names, for example
one of my golang packages (github.com/AudriusButkevicius/cli [1])
produces a "cli-%{shortcommit}" or "cli-%{version}.tar.gz" tarball
when using %gosource, which is why I manually changed the link to
AudriusButkevicius-cli-*.tar.gz back when I generated the .spec file
with gofed.

But you can't do that. The URL in the spec file is supposed to be auditable. Cut and pasting the url in any download tool should download the expected archive with the expected filename without any manual fixing. Changing the archive name in the end of a github URL still produces the file name you do not like in Firefox for example, so you have to live with this filename.

It is unfortunate that the archive naming conventions chosen by github and most of its competitors are so ambiguous, but we can not change them at Fedora level. It makes setting
%_sourcedir %{_topdir}/SOURCES/%{name}

in .rpmmacros almost mandatory when working with such hosting services.

5) I couldn't figure out how to correctly handle the "post-release
snapshot" case, where both "Version" and "%commit" have to be set. The
macros just generated a Release tag like for packaging a released
version, ignoring the "commit" tag completely.

That's one of the rewrite simplifications that does not work out in practice.

6) When I finally got the macros right enough for %prep, %build, and
%install to proceed, the build failed due to missing debuginfo files

This part is simple, just do not include a %build section if you're not building anything.

Thanks Igor (ignatenko) for pointing this out :). If the %build section is specified the rpm tries to create debuginfo rpm. Which it fails to do so as pure devel rpm does not ship any binary.

(and warnings about duplicate files)

This looks like a rewrite bug, I never had this with the original code I submitted :(

The contents of the .spec file at the point where I gave up trying to
get it to build successfully are available via this gist link:

Thank you for trying I hope we can make all this better soon.

I'll notify the list as soon as I've assembled a new PR that integrates my original code with the improvements Jan wrote in something that works for me, please retest it then and report if it works for you. Unless the redhat-rpm-config bit can move quickly it will probably require testing converted packages in a fedora-devel buildroot, I hope that's ok with you

Both go-srpm-macros and go-compilers can be updated pretty quickly, providing fixes and improvements in 30 minutes if needed. Please, open an issue on https://github.com/gofed/go-macros for each defect. Even if it is just a documentation issue.


devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to