On 13/12/2015 05:01, Steve Wills wrote: >> Perhaps you should make a tool which takes a go project as input and a >> > FreeBSD package as output?
> This is an interesting idea. It's a bit of work though and you're be > re-implementing pkg in go and chasing any changes it made. And I'm not > sure how it would integrate with ports. Not at all. Pkg is all about run-time dependencies and knows nothing at all about what it takes to build anything. That's what the ports tree is all about. As far as pkg is concerned, it doesn't matter how these go ports are compiled and how the results are divided into packages. If it makes sense to build a go program including whatever other go packages it depends on as one blob and then package up the results all together, then pkg is cool with that. The only concern is when the same dependency occurs for two different go programs (which is probably a good indication that dependency should be a separate pkg of its own.) So long as you don't generate conflicts by trying to install a file of the same name from more than one package, bundling all the dependencies in with the parent should work. Not saying that's a particularly good idea, or that installing essentially the same stuff distributed in multiple places around the filesystem is a particularly elegant concept -- clearly it isn't, but if it's a choice between 'elegant' or 'working' then working wins every time. The ports requirements are a different thing however. Yes, you will need to work out how to download all the distfiles for your go program as a separate step during the 'fetch' phase. All of those disfiles will need to be checksummed and matched against the recorded distinfo in the port. That's a big deal security-wise. Note that there is a very little used 'FETCH_DEPENDS' type of dependency where you can get the ports to install whatever else you need to manage the downloading part. Cheers, Matthew
signature.asc
Description: OpenPGP digital signature