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 :
Hi
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:
https://gist.github.com/decathorpe/366daeb50e889fcd9153eedb1b761804
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.
Regards,
Cheers
Jan
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
