Re: golang deps (rpms v/s bundled)
On Mon, Jan 26, 2015 at 10:09:04AM -0600, Lokesh Mandvekar wrote: On Mon, Jan 26, 2015 at 09:49:51AM -0600, Lokesh Mandvekar wrote: On Mon, Jan 26, 2015 at 01:29:34PM +0400, Peter Lemenkov wrote: 2015-01-26 3:17 GMT+03:00 Lokesh Mandvekar l...@fedoraproject.org: Hi all, I propose to prefer using vendored/bundled golang deps and use rpm dependencies only as a last resort for golang packages. This contradicts to the preferred Fedora practice and even if we agree on that, this should be elevated to FESCo. Ticket created: https://fedorahosted.org/fesco/ticket/1395 Please modify/correct/enhance if need be. FPC ticket: https://fedorahosted.org/fpc/ticket/496 Alright, updates continuing on the original golang packaging ticket: https://fedorahosted.org/fpc/ticket/382#comment:25 Feel free to dive in if you like. -- Lokesh Freenode, OFTC: lsm5 GitHub: @lsm5 GPG: 0xC7C3A0DD pgpqhOvzmQ0mh.pgp Description: PGP signature ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
Re: golang deps (rpms v/s bundled)
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 l...@fedoraproject.org Date: 01/25/2015 19:17 (GMT-05:00) To: golang@lists.fedoraproject.org Cc: epa...@fedoraproject.org,jchal...@fedoraproject.org,vba...@fedoraproject.org,pe...@fedoraproject.org,maxamill...@fedoraproject.org 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 golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
Re: golang deps (rpms v/s bundled)
2015-01-26 3:17 GMT+03:00 Lokesh Mandvekar l...@fedoraproject.org: Hi all, I propose to prefer using vendored/bundled golang deps and use rpm dependencies only as a last resort for golang packages. This contradicts to the preferred Fedora practice and even if we agree on that, this should be elevated to FESCo. I have a mixed feeling over this - although this indeed could simplify our life, I think we're opening a can of worms. -- With best regards, Peter Lemenkov. ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
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 pgp_mwpnIxcrr.pgp Description: PGP signature ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
RE: golang deps (rpms v/s bundled)
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 l...@fedoraproject.org Date: 01/25/2015 19:17 (GMT-05:00) To: golang@lists.fedoraproject.org Cc: epa...@fedoraproject.org,jchal...@fedoraproject.org,vba...@fedoraproject.org,pe...@fedoraproject.org,maxamill...@fedoraproject.org Subject: golang deps (rpms v/s bundled) Hi all,I propose to prefer using vendored/bundled golang deps and use rpm dependencies onlyas 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 golangdependencies used, thus making rpm dependencies redundant IMO. Using thebundled sources makes building packages a lot more convenient than dependingon rpms.I'm aware that the dependencies are different upstreams but since those arebundled 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 toupdate/use in docker/kube though props to jchaloup on making golang packaging very easy:https://github.com/ingvagabund/GolangPackageGeneratorAll that said, we could still continue to package golang repos in casesomeone needs it for something.I was hoping we could yay or nay on this andalso perhaps modify the golang packaging draft if everyone agrees.https://fedoraproject.org/wiki/PackagingDrafts/Go#DependenciesComments?PS: I'm doing this already for daily rebuilds of docker master branch onfedora rawhide starting today.-- LokeshFreenode, OFTC: lsm5GPG: 0xC7C3A0DD smime.p7s Description: S/MIME Cryptographic Signature ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
