Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Dec 2015 12:38:05 +0200
From:      Peter Pentchev <roam@ringlet.net>
To:        Malcolm Matalka <mmatalka@gmail.com>
Cc:        Piotr Florczyk <piotr.florczyk@gemius.com>, freebsd-ports@freebsd.org
Subject:   Re: poudriere, Go and networking
Message-ID:  <20151212103805.GA3370@straylight.m.ringlet.net>
In-Reply-To: <86mvthrndh.fsf@gmail.com>
References:  <374B9F2C-11B4-44F6-9FF6-E4687ECF9CB2@gemius.com> <20151211143601.GI35480@home.opsec.eu> <566AE71B.3080201@gemius.com> <86mvthrndh.fsf@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 11, 2015 at 03:55:22PM +0000, Malcolm Matalka wrote:
> Piotr Florczyk <piotr.florczyk@gemius.com> writes:
>=20
> > 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. P=
oudriere
> >>> 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=3D188110#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 i=
t 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.
>=20
> 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 net=
work at some later stage than post-extract. In my opinion we might
> > aswell move it to that point right now.
>=20
> 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

--=20
Peter Pentchev  roam@ringlet.net roam@FreeBSD.org pp@storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

--+HP7ph2BbKc20aGI
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJWa/kJAAoJEGUe77AlJ98TA/UQAJyV6MbWgtEVfQ5JcQfigmUH
K7tHVCk5vsv2gQj6NvXHGk3NOzNxLKkxj+00lfYK36c7HMsTnMkP9M3H/dnzuxY7
KjlAxVTBlhP8+gfA1tubKO5fQuGB0DI07M+ic6MNmkxNBNslfHqEdBe8YmEUjxFT
5FBczcdDjzDrBywRAyxR4bShuwYlDo1BlD6EMOUw1dcsE30ntTzycqL70WTUOVpw
oLVNJGNEon54fwaApAYbTtlcI0z7ZVQzViP+JIMCPLkd52NxtZMSB70WZxMwoNUm
fpToPxs/0b4ptMM3K9SsstTHjE8QLXZAfGhQut90Wz3SvKnX/cBdCtr4v5f6lrHu
dmR3q85weSXItLxWWW41qdz8aRL446PS9j941Ll2BQffMKrmezQ39gHWlJBf10I+
bpv+9vtyIca5Ydd2MHy7H7c4b5pSUISzPXSMWlMs231XEI2oPbXxvrGJnBkuY/Vv
NFVsmnKNa2bdmluHtGjzzUj15Lre2tnYl12bU3k/nrfMF15h6nB64u7VtIxVU1+S
5qVTl+pWuxNlfxNSJo5vJsBgHwx4PEaCuz3v5w0PVHfrzmYOLeZCLC1WiVi9EzKR
swN2GKa0seaqFXsIyGBLKijYDpcSlBU2hxY6VN5fFNpm7lz4v+5PXHYfEkTBeAyC
UYGTtYHzIA6iGh8jHzcx
=dKmr
-----END PGP SIGNATURE-----

--+HP7ph2BbKc20aGI--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151212103805.GA3370>