Date: Fri, 11 Dec 2015 21:37:39 +0100 From: Kurt Jaeger <lists@opsec.eu> To: Piotr Florczyk <piotr.florczyk@gemius.com> Cc: freebsd-ports@freebsd.org Subject: Re: poudriere, Go and networking Message-ID: <20151211203739.GL35480@home.opsec.eu> In-Reply-To: <566AE71B.3080201@gemius.com> References: <374B9F2C-11B4-44F6-9FF6-E4687ECF9CB2@gemius.com> <20151211143601.GI35480@home.opsec.eu> <566AE71B.3080201@gemius.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! > >> Recently I had to package couple of programs written in Go and godep is > >> becoming the standard for dependency tracking in Go projects. > >> [...] Poudriere > >> disables networking after fetch phase and I don't know before extract > >> phase what dependencies are inside. > > We recently upgraded maven, the java-world 'make and godep' and all > > the ports that need maven to build have the same problem, see: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188110#c37 > > I think we need some fancy fetch target per distfile which basically > > uses technology-dependend (maven, godep, etc) ways to trigger > > the 'fetch' during the fetch-phase. Probably some sort > > of base-fetch vrs. dep-fetch ? > New target might not be needed but I think this is good idea. >From my understanding, the new target is needed because we make a three-step process out of a one-step one: Currently: fetch -> extract -> etc. Then: fetch -> extract -> find-deps -> fetch-deps In theory, the deps could also be listed and checked against distinfo. In practice, this would no be easy to implement, but it would be the clean way on how to handle it. I doubt it would be easy to implement in one step. > Altough it > does not solve my problem with poudriere. In my case, the soonest I can > fetch dependencies is in post-extract target. So if poudriere didn't cut > off networking at this stage we wouldn't need any changes and every one > would be happy. It would work, as a shortcut, but the problem is not poudriere, it's the build-process in general. There's a reasoning behind the restriction, but I cant remember... > Even if we come up with proper solution it will require cutting off > network at some later stage than post-extract. In my opinion we might > aswell move it to that point right now. -- pi@opsec.eu +49 171 3101372 5 years to go !
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151211203739.GL35480>