Re: Re: Trying out More Go Packaging: Bugs and Questions
Le mercredi 07 mars 2018 à 16:35 +0100, Nicolas Mailhot a écrit : > Le mercredi 07 mars 2018 à 16:02 +0100, Jan Chaloupka a écrit : > > Hi, > > > Nicolas, can you more elaborate on that? I don't see any more reason > > why we should block folks from relying on the new macros. > > IMHO they're solid enough to be used in production both for binary > packages and -devel packages (modulo the fixes which are in the PRs I > sent you). > > The remaining work (also to clean up the way golist is assembled and built, but that need not change the way other packages use it) -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: Re: Trying out More Go Packaging: Bugs and Questions
Hi Athos,
hope everything is fine and you have better things to do than spending
much time updating the Go spec files :)
Anything you need and/or anything that could help you to minimize your
packaging time, please, let us know :).
On 03/04/2018 08:20 PM, Nicolas Mailhot wrote:
Le samedi 03 mars 2018 à 11:47 -0300, Athos Ribeiro a écrit :
Are there any intentions to push the macros into f28? I really liked
the
improvements in the spec file sizes, but porting too many packages now
and keep them updated in both f28 and rawhide (making the branches
completely different) would mean a lot of extra work. Or maybe I am
just
too late here since we are quite close from the beta freeze.
The intention is to get everything in a state everyone likes in -devel,
and then push it back to as many stable releases as possible (including
maybe EL7, EL6 really seems too old)
I took a liberty and pushed the new macros into f27+ yesterday.
The naming and API of each macro should be pretty stable now.
There may be slight changes in the API but that should not be fatal.
Feel free to update you packages on f27+ and let us know if there are
any difficulties :).
The nice thing about using new macro names is that is can not break any
existing spec file, unchanged specs just won't see the changes (except
maybe %gotest, we had to change it brutally because of its insane
argument structure)
+1
The tooling work has progressed a lot those past days, it should now be
able to accommodate both Jan's workflow and mine. The remaining sticking
points are:
1. have the redhat-rpm-config maintainers push the %forge macros to
stable as they promised, now we're reasonably sure they are bug-free
Once the macro.forge are available in f27+ (maybe even f26), I will be
more than happy
to dispose all the fallback code I added so the new macros work on f27+.
2. testing testing (help appreciated)!
Definitely. Anything you feel is not right or does not work as expected,
feel free to open an issue on https://github.com/gofed/go-macros .
2. fixing (ditto)
3. defining a form of default policy (right now we have lots of flags to
exclude things in install/check/autodeps, but no real opinion on what
exclusions make sense)
Agree, so far most of the Go projects I have encountered with seems
pretty default. But you never know.
The more "exotic" layouts we have, the more logic we can put into the
macros so the packaging is still user-friendly.
4. documenting the changes in the wiki (help *very* appreciated)!
The latest code is in:
https://github.com/gofed/symbols-extractor/ (for the go code)
https://github.com/gofed/go-macros (for Jan's version of macros and
scripts) or
https://github.com/nim-nim/go-macros/tree/improve-integration (for the
changes I did and Jan didn't merge yet)
…and of course in go-compilers and go-srpm-macros whenever Jan does a
build.
I works fine in the simple tests I had time to do, without the warts and
problems reported after the initial merge. Still have some ideas on how
to improve handling of test and example code
Let's please keep in mind we still need to do decide what we are going
to do with both wikis.
I would like to consolidate both [1] and [2] documents into a single one
so there is only
one source of truth about the Go packaging.
[1] https://fedoraproject.org/wiki/PackagingDrafts/Go
[2] https://fedoraproject.org/wiki/More_Go_packaging
Major changes, by memory:
1. revert to %gometa and %forgemeta like documented in the wiki, you can
forget about providerprefix
2. %goinstall now computes project files that need installation, you
don't need the gofiles=$( line anymore. Though of course you can specify
additional files to install as %goinstall arguments. Passing a file
goinstall already wants to install should be transparent without
duplicated file warnings
3. you can add files by extension in goinstall with -e
4. you can specify another import path to goinstall with -i (though that
does not change how code actually references itself so YMMV)
5. new -d -t -r flags to exclude honoured by pretty much all the macros,
read the doc in the macro files of in %{_bindir}/go-rpm-integration
6. lots of tweaks that should be mostly invisible but make things do the
right thing automatically as much as possible
7. automated md file installation and marking as %doc %gocolllectmd is
dead (in my version, not merged by Jan yet)
8. primitive detection of bundled code (but please just rm -fr vendor)
9. lots of weird user cases now work, even if I'm not sure they're all a
good idea
Anyway if someone wants to test the files, check the spec programmingAPI is
convenient and sane, and update
https://fedoraproject.org/wiki/More_Go_packaging
with the changes help would be very appreciated.
We tried to keep API changes to the minimum, but there are some, and I'm
not sure I remember all of them, new eyes would be good.
Regards,
Cheers
Jan
___
devel mail
Re: Re: Trying out More Go Packaging: Bugs and Questions
On 02/27/2018 07:22 PM, Nicolas Mailhot wrote: Le mardi 27 février 2018 à 18:34 +0100, Robert-André Mauchin a écrit : How do we test this? I installedtho go-srpm-macros from Rawhide but it doesn't seem to have the required macros? Yes in rawhide go-compilers and go-srpm-macros are in an intermediary not fully tested/integrated state. The original PR that matched what's in the wiki and is known to work is here https://src.fedoraproject.org/rpms/go-compilers/pull-request/2 Just grab the files rebuild the resulting go-compilers package and you're set to try it on your projects (in a fedora-devel buildroot) I'll try to mix it with all the nice work Jan did to keep all the parts where he improved the implementation without the loss of integration polish of the go-srpm-macros and go-compilers packages he pushed to fedora-devel. And I definitely do not want something that requires rewriting the wiki once again :) Regards, The latest go-srpm-macros and go-compilers ship the latest version of the new macros. Please, let us now if it still does not work for you :). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: Re: Trying out More Go Packaging: Bugs and Questions
Le samedi 03 mars 2018 à 11:47 -0300, Athos Ribeiro a écrit :
>
> Are there any intentions to push the macros into f28? I really liked
> the
> improvements in the spec file sizes, but porting too many packages now
> and keep them updated in both f28 and rawhide (making the branches
> completely different) would mean a lot of extra work. Or maybe I am
> just
> too late here since we are quite close from the beta freeze.
The intention is to get everything in a state everyone likes in -devel,
and then push it back to as many stable releases as possible (including
maybe EL7, EL6 really seems too old)
The nice thing about using new macro names is that is can not break any
existing spec file, unchanged specs just won't see the changes (except
maybe %gotest, we had to change it brutally because of its insane
argument structure)
The tooling work has progressed a lot those past days, it should now be
able to accommodate both Jan's workflow and mine. The remaining sticking
points are:
1. have the redhat-rpm-config maintainers push the %forge macros to
stable as they promised, now we're reasonably sure they are bug-free
2. testing testing (help appreciated)!
2. fixing (ditto)
3. defining a form of default policy (right now we have lots of flags to
exclude things in install/check/autodeps, but no real opinion on what
exclusions make sense)
4. documenting the changes in the wiki (help *very* appreciated)!
The latest code is in:
https://github.com/gofed/symbols-extractor/ (for the go code)
https://github.com/gofed/go-macros (for Jan's version of macros and
scripts) or
https://github.com/nim-nim/go-macros/tree/improve-integration (for the
changes I did and Jan didn't merge yet)
…and of course in go-compilers and go-srpm-macros whenever Jan does a
build.
I works fine in the simple tests I had time to do, without the warts and
problems reported after the initial merge. Still have some ideas on how
to improve handling of test and example code
Major changes, by memory:
1. revert to %gometa and %forgemeta like documented in the wiki, you can
forget about providerprefix
2. %goinstall now computes project files that need installation, you
don't need the gofiles=$( line anymore. Though of course you can specify
additional files to install as %goinstall arguments. Passing a file
goinstall already wants to install should be transparent without
duplicated file warnings
3. you can add files by extension in goinstall with -e
4. you can specify another import path to goinstall with -i (though that
does not change how code actually references itself so YMMV)
5. new -d -t -r flags to exclude honoured by pretty much all the macros,
read the doc in the macro files of in %{_bindir}/go-rpm-integration
6. lots of tweaks that should be mostly invisible but make things do the
right thing automatically as much as possible
7. automated md file installation and marking as %doc %gocolllectmd is
dead (in my version, not merged by Jan yet)
8. primitive detection of bundled code (but please just rm -fr vendor)
9. lots of weird user cases now work, even if I'm not sure they're all a
good idea
Anyway if someone wants to test the files, check the spec programmingAPI is
convenient and sane, and update
https://fedoraproject.org/wiki/More_Go_packaging
with the changes help would be very appreciated.
We tried to keep API changes to the minimum, but there are some, and I'm
not sure I remember all of them, new eyes would be good.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: Trying out More Go Packaging: Bugs and Questions
On Tue, Feb 27, 2018 at 07:22:42PM +0100, Nicolas Mailhot wrote: > Le mardi 27 février 2018 à 18:34 +0100, Robert-André Mauchin a écrit : > > > > > > How do we test this? I installedtho go-srpm-macros from Rawhide but it > > doesn't seem to have the required macros? > > Yes in rawhide go-compilers and go-srpm-macros are in an intermediary > not fully tested/integrated state. > > The original PR that matched what's in the wiki and is known to work is > here > https://src.fedoraproject.org/rpms/go-compilers/pull-request/2 > > Just grab the files rebuild the resulting go-compilers package and > you're set to try it on your projects (in a fedora-devel buildroot) > > I'll try to mix it with all the nice work Jan did to keep all the parts > where he improved the implementation without the loss of integration > polish of the go-srpm-macros and go-compilers packages he pushed to > fedora-devel. And I definitely do not want something that requires > rewriting the wiki once again :) Are there any intentions to push the macros into f28? I really liked the improvements in the spec file sizes, but porting too many packages now and keep them updated in both f28 and rawhide (making the branches completely different) would mean a lot of extra work. Or maybe I am just too late here since we are quite close from the beta freeze. Thanks for the hard work though :) -- Athos Ribeiro http://www.ime.usp.br/~athoscr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: Trying out More Go Packaging: Bugs and Questions
Le mardi 27 février 2018 à 18:34 +0100, Robert-André Mauchin a écrit : > > > How do we test this? I installedtho go-srpm-macros from Rawhide but it > doesn't seem to have the required macros? Yes in rawhide go-compilers and go-srpm-macros are in an intermediary not fully tested/integrated state. The original PR that matched what's in the wiki and is known to work is here https://src.fedoraproject.org/rpms/go-compilers/pull-request/2 Just grab the files rebuild the resulting go-compilers package and you're set to try it on your projects (in a fedora-devel buildroot) I'll try to mix it with all the nice work Jan did to keep all the parts where he improved the implementation without the loss of integration polish of the go-srpm-macros and go-compilers packages he pushed to fedora-devel. And I definitely do not want something that requires rewriting the wiki once again :) Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
