On Fri, Dec 11, 2015 at 03:55:22PM +0000, Malcolm Matalka wrote: > Piotr Florczyk <piotr.florc...@gemius.com> writes: > > > W dniu 11.12.2015 o 15:36, Kurt Jaeger pisze: > >> Hi! > >> > >>> Recently I had to package couple of programs written in Go and godep is > >>> becoming the standard for dependency tracking in Go projects. > >>> For example I currently had to package telegraf. Here is the thing. > >>> 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 > >> > >>> So here is the question: would it be possible to have networking > >>> enabled during extract phase ? > >>> Or maybe there is another solution (some flag in ports maybe that > >>> I'm missing ?) > >> > >> 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. 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. > > This sounds like it would be a security hole to let a package download > extra things that the FreeBSD package system does not know about and > cannot validate.
FWIW, this is my personal opinion, too. The FreeBSD Ports Collection is supposed to be self-sufficient: - anything a port needs should be available as, well, another port - any changes to what a port needs should be vetted by the maintainer at the time of updating the port - anybody should, at any time, be able to find out what a port depends on and what other ports depend on it using only "static" information from the ports tree That last point is pretty important for people who maintain ports of libraries or other widely-used software: sometimes, when preparing an update to a new upstream version with important changes, it is very nice to be able to test by yourself if these changes will break other ports that depend on yours (or, of course, drop an e-mail to the maintainers of these other ports saying "hey, here's a proposed update to my port, could you check if it'll break yours?"). > > 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. > > Perhaps you should make a tool which takes a go project as input and a > FreeBSD package as output? This sounds like the way to go. The Debian Perl group has a tool that goes by many names, but in at least one of its incarnations, cpan2deb, it does exactly that - downloads a package from the CPAN archive, examines its metadata files to find out what it needs, looks for these dependencies in the Debian package archive, and outputs a skeleton of a package that has these dependencies listed in the proper fields. Of course, it may also do this later, after the package has been updated and its dependencies have changed. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p...@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature