Hi Robert-André,
thank you for your patience and all comments pointing out pieces that
are not working as expected.
Introduction of new macros is a time-consuming process and it requires
resilience so we keep up till the state
where the macros are generally usable for a lot of our use cases. Making
the packaging experience as easy as possible at the same time.
On 02/27/2018 07:39 PM, Robert-André Mauchin wrote:
On mardi 27 février 2018 15:49:44 CET Fabio Valentini wrote:
Hi everybody,
I've been following the (long overdue) improvements concerning go packaging
in fedora, and since I saw that packages are starting to make use of the
new mechanisms, I wanted to finally check it out and started "converting"
one of my own (one of ~50) golang packages
(golang-github-AudriusButkevicius-cli). However, I came across a few
stumbling blocks (and at least one bug) in the current implementation
(please correct me if I am just doing it wrong):
1) The currently implemented macros have different names than the ones that
were proposed at the "More Go Packaging" wiki page, which confused me. I
had to look at a recently "converted" package to figure out the correct
macro names. I guess the documentation just hasn't caught up yet here.
The "More Go Packaging" wiki page is in most parts very well written
piece of document.
Touching very important topics and suggesting improvements that makes
maintenance easier.
Unfortunately, it was published before the new macros were merged into
Fedora.
Though, it is important to be proactive so my thanks to Nicolas for
sharing his experience in the area.
And yes, the macros are not the same as mentioned in the document. It
took us some time to agree
on common ground and way the macro should be implemented and provided.
We have not finished
the discussion but I am happy we managed to converge to the current
state we can agree on.
Meantime, I started publishing at least some of the macros so they can
be incrementally tested.
2) Additionally, I wasn't able to figure out why I have to set both
"%gobaseipath" and "%provider_prefix".
Yes this is redondant. I was prefering to use %forgeurl if necessary.
By the time I joined the Go packaging effort (~3.5y ago) I introduced
two macros that goes hand in hand:
- %provider_prefix for repository providing tarball with source code
- %import_path storing import path prefix the source code tarball provides
I have build a tooling that scans Go packages in the distribution and
understands the macros.
By the time Nicolas introduced his forgeurl macro, I was not fully aware
of its meaning so I kept the original one.
After learning provider_prefix is equivalent to forgeurl, I switched to
it as the new forgemeta proved to simplify
the spec file meta data specification (including manipulation with
Release tag).
In most cases the change is compatible with my tooling. However, there
are some drawbacks
I will have to iterate on so the tooling is operational again. Though,
it should not affect any spec file
up to defining some additional macros if a packager wishes to include
the spec file for automatic distribution-scoped analysis.
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.
I sent a PR for this.
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.
6) When I finally got the macros right enough for %prep, %build, and
%install to proceed, the build failed due to missing debuginfo files (and
warnings about duplicate files) - well, it's a source-only library package,
how do I specify this with the new macros?
I have the same problem, looking at the log it seems every command is run twice? Thus it lists the files twice.
Also the file list is containing folders than should't be there:
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748/_build"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748/_build/src"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748/_build/src/bazil.org"
These seems to be remnant from the build process and shouldn't be included.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Regards
Jan
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
