Re: [pkg-go] a mutual dependency problem (Packer)
On 15.04.2016 02:10, Dmitry Smirnov wrote: > On Thursday, 14 April 2016 10:38:15 PM AEST Daniel Stender wrote: >> I have an idea but wanted to poll, how could get they both in the best way? > > Not sure for "best way" but here some ideas how this problem could be > addressed: > > Sometimes one dependency required only by tests. In such case it may be safe > to disable corresponding tests in order to break/remove circular dependency. > > Since Packer appears to be a bigger package it is likely that you are > packaging "winrmcp" merely to satisfy dependency of Packer. There are two > options: > > * To keep bundled/vendored version of "winrmcp" in Packer and do not package > "winrmcp" separately; > > * To keep bundled/vendored portion of Packer code in "winrmcp". > > I would investigate those options in given order. Whatever you choose please > remember to leave a note explaining your decision in README.source. I've solved the problem at winrmcp with a patch which injects the needed code, and upstream in the meanwhile was so nice to break the circular dependency by using another UUID package. Packer itself has another problem, the lately packaged update of azure-sdk (2.1.1~beta, 2016-04-12) already breaks Packer 0.10.0, which vendors 1.2+334-95361a2 (2016-02-10). Do people have pointers to Go packages already in the archive by the hand which are vendoring some third-party code which could work as a model how to solve this? Thanks, DS -- 4096R/DF5182C8 http://www.danielstender.com/blog/ ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] a mutual dependency problem (Packer)
On 15.04.2016 02:10, Dmitry Smirnov wrote: > On Thursday, 14 April 2016 10:38:15 PM AEST Daniel Stender wrote: >> I have an idea but wanted to poll, how could get they both in the best way? > > Not sure for "best way" but here some ideas how this problem could be > addressed: > > Sometimes one dependency required only by tests. In such case it may be safe > to disable corresponding tests in order to break/remove circular dependency. > > Since Packer appears to be a bigger package it is likely that you are > packaging "winrmcp" merely to satisfy dependency of Packer. There are two > options: > > * To keep bundled/vendored version of "winrmcp" in Packer and do not package > "winrmcp" separately; > > * To keep bundled/vendored portion of Packer code in "winrmcp". > > I would investigate those options in given order. Whatever you choose please > remember to leave a note explaining your decision in README.source. Hi Dmitry, thx for comments. Yes, vendoring would be another option. I'll see. Best, Daniel -- 4096R/DF5182C8 http://www.danielstender.com/blog/ ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] a mutual dependency problem (Packer)
On 15.04.2016 00:41, Ximin Luo wrote: > Daniel Stender: >> Hi, >> >> there's a problem with packaging Packer [1]: github-packer-community-winrmcp >> [2] needs >> the sources of Packer (import "github.com/mitchellh/packer/common/uuid"), >> while Packer >> needs the sources of winrmcp (import >> "github.com/packer-community/winrmcp/winrmcp") [3], >> so there's a mutual dependency. >> >> Both packages are going to have two binary packages, one carrying the >> compiled application >> and another "-dev" package carrying just the source (like Consul [3] and >> winrm [4]). >> >> I have an idea but wanted to poll, how could get they both in the best way? >> >> Thanks in advance, >> Daniel Stender >> >> [1] https://bugs.debian.org/740753 (Packer ITP) >> >> [2] https://bugs.debian.org/809051 (winrmcp ITP) >> >> [3] https://tracker.debian.org/pkg/consul >> >> [4] https://tracker.debian.org/pkg/golang-github-masterzen-winrm >> > > The only clean way is to fix it upstream. Circular build dependencies make > lots of things stupidly painful and require extra tooling to handle. > Sometimes it's necessary like for compilers[1] but most projects aren't > special snowflakes like that. > > If you really must (i.e. you failed to convince either upstream after lots of > trying) you can try to break the circle by building parts of one of the > packages using "build profiles", search for DEB_BUILD_PROFILE. The idea is to > build a subcomponent of one package using a special profile, that gives you > something to bootstrap the other one with. I don't know the details myself > though. > > X > > [1] and even in this case it ideally should be a self-dependency, i.e. a > cycle of size 1 not >1. I hear rustc is headed in the opposite direction. :( Yes, it would be best if this could be solved upstream. I've filed an issue of this [1] and will take if look if we could provide a patch to replace github.com/mitchellh/packer/common/uuid. Thx for comments. DS [1] https://github.com/packer-community/winrmcp/issues/12 -- 4096R/DF5182C8 http://www.danielstender.com/blog/ ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] a mutual dependency problem (Packer)
On Thursday, 14 April 2016 10:38:15 PM AEST Daniel Stender wrote: > I have an idea but wanted to poll, how could get they both in the best way? Not sure for "best way" but here some ideas how this problem could be addressed: Sometimes one dependency required only by tests. In such case it may be safe to disable corresponding tests in order to break/remove circular dependency. Since Packer appears to be a bigger package it is likely that you are packaging "winrmcp" merely to satisfy dependency of Packer. There are two options: * To keep bundled/vendored version of "winrmcp" in Packer and do not package "winrmcp" separately; * To keep bundled/vendored portion of Packer code in "winrmcp". I would investigate those options in given order. Whatever you choose please remember to leave a note explaining your decision in README.source. -- Best wishes, Dmitry Smirnov. --- For a creative writer possession of the 'truth' is less important than emotional sincerity. -- George Orwell signature.asc Description: This is a digitally signed message part. ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] a mutual dependency problem (Packer)
Daniel Stender: > Hi, > > there's a problem with packaging Packer [1]: github-packer-community-winrmcp > [2] needs > the sources of Packer (import "github.com/mitchellh/packer/common/uuid"), > while Packer > needs the sources of winrmcp (import > "github.com/packer-community/winrmcp/winrmcp") [3], > so there's a mutual dependency. > > Both packages are going to have two binary packages, one carrying the > compiled application > and another "-dev" package carrying just the source (like Consul [3] and > winrm [4]). > > I have an idea but wanted to poll, how could get they both in the best way? > > Thanks in advance, > Daniel Stender > > [1] https://bugs.debian.org/740753 (Packer ITP) > > [2] https://bugs.debian.org/809051 (winrmcp ITP) > > [3] https://tracker.debian.org/pkg/consul > > [4] https://tracker.debian.org/pkg/golang-github-masterzen-winrm > The only clean way is to fix it upstream. Circular build dependencies make lots of things stupidly painful and require extra tooling to handle. Sometimes it's necessary like for compilers[1] but most projects aren't special snowflakes like that. If you really must (i.e. you failed to convince either upstream after lots of trying) you can try to break the circle by building parts of one of the packages using "build profiles", search for DEB_BUILD_PROFILE. The idea is to build a subcomponent of one package using a special profile, that gives you something to bootstrap the other one with. I don't know the details myself though. X [1] and even in this case it ideally should be a self-dependency, i.e. a cycle of size 1 not >1. I hear rustc is headed in the opposite direction. :( -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] a mutual dependency problem (Packer)
Hi, there's a problem with packaging Packer [1]: github-packer-community-winrmcp [2] needs the sources of Packer (import "github.com/mitchellh/packer/common/uuid"), while Packer needs the sources of winrmcp (import "github.com/packer-community/winrmcp/winrmcp") [3], so there's a mutual dependency. Both packages are going to have two binary packages, one carrying the compiled application and another "-dev" package carrying just the source (like Consul [3] and winrm [4]). I have an idea but wanted to poll, how could get they both in the best way? Thanks in advance, Daniel Stender [1] https://bugs.debian.org/740753 (Packer ITP) [2] https://bugs.debian.org/809051 (winrmcp ITP) [3] https://tracker.debian.org/pkg/consul [4] https://tracker.debian.org/pkg/golang-github-masterzen-winrm -- 4096R/DF5182C8 http://www.danielstender.com/blog/ ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
