Packaging of all dependencies is not an ultimate weapon. Some packages
already introduce cyclic dependencies. From that reason, some packages
no longer [Build]Requires all dependencies. As almost all of them (~95%)
are source codes, we don't have to take care of situations when packages
A (e.g. kubernetes) provides binaries and devel sources in two separate
builds and buildrequires on a package that requires kubernetes devel
subpackage. Some repos already suffer these deformations but it is still
possible to work around this by deleting some BuildRequires/Requires and
not running go test. But sooner or later it will get to a point when
there are two packages A and B which BuildRequires each other and both
are building from its source codes. Another case is where two packages
uses different commits of source codes from the same package. Here we
blindly suppose a back-compatibility. But when unnamed someone decides
to rename import paths, it does not have to be so true as some repos
does not change to the new import path prefix. Or moving
code.google.com/p/ ... repos into github or to a new
https://code.googlesource.com/PROJECT. So using bundled source codes
saves us a lot of trouble (and packaging time).
Definitely we need a limitation on what is still suitable to package and
what is not.
Jan
On 01/26/2015 03:38 AM, Vincent Batts wrote:
I love bundling, though this is all in the light of ideal upstream
situations. Active and making updates. The biggest drawback will be
when/if upstream lags and becomes out of sync of security updates of
bundled source. Then the risks are flying under the radar. Otherwisr,
I am in huge support of working towards what works best and moving the
golang packaging guidelines forward.
-------- Original message --------
From: Lokesh Mandvekar <[email protected]>
Date: 01/25/2015 19:17 (GMT-05:00)
To: [email protected]
Cc:
[email protected],[email protected],[email protected],[email protected],[email protected]
Subject: golang deps (rpms v/s bundled)
Hi all,
I propose to prefer using vendored/bundled golang deps and use rpm
dependencies only
as a last resort for golang packages.
Short story long: quite a few golang packages like docker, kubernetes
and (hopefully soon)
rocket provide a dir like 'vendor/' or 'Godeps/' which includes the golang
dependencies used, thus making rpm dependencies redundant IMO. Using the
bundled sources makes building packages a lot more convenient than
depending
on rpms.
I'm aware that the dependencies are different upstreams but since
those are
bundled along with the main tool, perhaps we can relax that restriction.
As most of you may have already experienced, golang deps are a huge
PITA to
update/use in docker/kube though props to jchaloup on making golang
packaging very easy:
https://github.com/ingvagabund/GolangPackageGenerator
All that said, we could still continue to package golang repos in case
someone needs it for something.
I was hoping we could yay or nay on this and
also perhaps modify the golang packaging draft if everyone agrees.
https://fedoraproject.org/wiki/PackagingDrafts/Go#Dependencies
Comments?
PS: I'm doing this already for daily rebuilds of docker master branch on
fedora rawhide starting today.
--
Lokesh
Freenode, OFTC: lsm5
GPG: 0xC7C3A0DD
_______________________________________________
golang mailing list
[email protected]
https://lists.fedoraproject.org/mailman/listinfo/golang
