On 2020/02/08 23:39, Joerg Jung wrote: > On Sat, Feb 01, 2020 at 03:29:25AM -0500, Raymond E. Pasco wrote: > > - I used a modified distfile provided by abieber with a vendor directory, > > which is necessary due to the large number of go package dependencies. > > IMHO, bundling things defeats the purpose of ports/package system. What > do you do if a dependency got a security update? Grep all distfiles if > bundled somewhere and re-roll and depend on abieber (no offense!) to > handle that? > > How about adding the dependencies as own ports instead? We do the same > for python, perl, etc. I know, this is a lot of work, may be portgen > can be tricked into handling go first...
Python and Perl's own packaging systems are generally friendly with standard OS packaging systems (sometimes incompatible changes happen and we have to update a chain of ports to handle it, but these affect users on all OS so it doesn't usually stay a big problem for too long). go (and others like node/npm, rust/cargo, maven) standard ecosystems work differently - actively encouraging incompatible changes by providing the mechanism to pin to a particular version as standard - and in most cases by statically linking so there's no conflict with files on disk. The downside as you rightly say is that security updates don't propagate, but that's baked into the whole ecosystem, it's not sanely possible to change that in ports. If we did try to then: - we would be actively fighting build systems to do what we want. it's already tricky enough to avoid network fetches during build (though this does seem to be getting better), but converting these dependencies to ports would be orders of magnitude worse - we would likely need to have multiple incompatible versions of the same thing to satisfy different dependencies - with static-linked languages we would still have to chase the dependency tree and bump revisions every time we update a "library" port (it's not like it would even save disk space), we don't have the shared library version mechanism, or even "load at runtime" like perl/python to let us bypass this It would be possible to convert to a multi-distfile port instead (like rust/cargo ports do) but really we need better infrastructure before that's a good idea - until that happens bundling a vendored tarball makes it *easier* to update (as long as there's a comment in the Makefile showing how) than making it multi-distfile. > > - aerc can be built with notmuch support, but notmuch isn't in ports (yet?), > > so I didn't bother with this. > > There were some submissions for notmuch in the past, but afaik never > imported. It isn't finished. It still has use-after-frees and some other problems showing up in the test suite.
