https://bugzilla.redhat.com/show_bug.cgi?id=1301143
--- Comment #8 from Antonio Murdaca <amurdaca(a)redhat.com> ---
(In reply to Jan Chaloupka from comment #7)
btw. a lot of new dependencies :)
$ gofed repo2spec --detect
github.com/runcom/skopeo --with-build --with-extra
Repo URL:
github.com/runcom/skopeo
Commit: 572a6b6f537d71f7cabfdcfe185c6d7cb4367272
Name: golang-github-runcom-skopeo
(1/4) Checking if the package already exists in PkgDB
(2/4) Downloading tarball
(3/4) Generating spec file
(4/4) Discovering golang dependencies
Class:
github.com/Azure/go-ansiterm (golang-github-Azure-go-ansiterm)
PkgDB=False
Class:
github.com/Sirupsen/logrus (golang-github-Sirupsen-logrus) PkgDB=True
Class:
github.com/codegangsta/cli (golang-github-codegangsta-cli) PkgDB=True
Class:
github.com/docker/distribution (golang-github-docker-distribution)
PkgDB=False
Class:
github.com/docker/docker (docker) PkgDB=False
Class:
github.com/docker/engine-api (golang-github-docker-engine-api)
PkgDB=False
Class:
github.com/docker/go-connections
(golang-github-docker-go-connections) PkgDB=False
Class:
github.com/docker/go-units (golang-github-docker-go-units) PkgDB=False
Class:
github.com/docker/libtrust (golang-github-docker-libtrust) PkgDB=True
Class:
github.com/go-check/check (golang-github-go-check-check) PkgDB=False
Class:
github.com/gorilla/context (golang-github-gorilla-context) PkgDB=True
Class:
github.com/gorilla/mux (golang-github-gorilla-mux) PkgDB=True
Class:
github.com/opencontainers/runc (golang-github-opencontainers-runc)
PkgDB=False
Class:
github.com/vbatts/tar-split (golang-github-vbatts-tar-split)
PkgDB=False
Class:
golang.org/x/net (golang-googlecode-net) PkgDB=True
Spec file golang-github-runcom-skopeo.spec at
/home/jchaloup/Packages/reviews/skopeo/golang-github-runcom-skopeo/fedora/
golang-github-runcom-skopeo
Yes, those new dependencies come from the master branch, I can tag a new
release and add all those dependencies :)
(In reply to Jan Chaloupka from comment #6)
Wondering if it would be better to create github repository (e.g.
fedora/golang-reviews) and instead of posting links to spec to post links to
pull request and comment in the PR. Missing feature to comment lines of the
spec file.
Well, the devel subpackage is usefull for analysis. When the devel
subpackage is present, it can be scanned for dependencies and other info
about the code. At the moment we are running simple scans of new builds of
golang projects in Koji. In future, we plan to report missing or broken
dependencies. So if you provide the devel subpackage, you get automatic
scans and reports about health of your package.
Second, I would recommend to add some macro at the top of the spec. E.g.
commit, provider_prefix, import_path. They are used for automatic updates of
spec file (e.g. 'gofed bump') and in analysis (as described above).
Third, you are using 'go build' inside Makefile. So your project can be
built on architectures with golang compiler only. If you move the commands
into %build section, you can use %gobuild macro a gain support for debugingo
and architectures with gcc-go compiler.
You can play with gofed for a while, try to run:
# yum install gofed
$ gofed repo2spec --detect
github.com/runcom/skopeo --with-build --with-extra
Bad news is it depends on docker so the devel subpackage will not be
complete. The good new is you can build the project from bundled
dependencies.
Lokesh, we should definitely do something about the docker. This is another
project that depends on it.
If this is happening we should at least
partially built the package from bundled and partially from debundled deps.
This is what I'm actually doing - I'm removing each bundled deps with rm -rf
/vendor and just leave under vendor the ones from docker which cannot be
debundled :)
At this point this is out of the question as we are still missing
automatic
tools that would do all the hard work for us.
--
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