Update on porting mono 5

[Romain Tartière]

On Fri, Aug 25, 2017 at 09:41:43PM +0200, David Naylor wrote:
> [2] A general discussion needs to be had around nuget packages.  How do we 
> consume them?
>   i) as downloads with each port containing a copy
>  ii) local ports with consistency across the Ports Collections
> iii) A mixture of the above (i.e. (ii) is there is a native component, 
> otherwise (i))
> I prefer (ii) as I think it gives the end user the best leverage to patch 
> issues with nuget packages locally (and to get updates without waiting on a) 
> upstream, and b) us/ports maintainer).  However, at this point that option is 
> at 0% progress.  

Yeah, it's a problem that is broader and broader…  and for which I don't
think a universal solution works :-/

With local copies (i) you end-up with a lot of duplication (Go
applications are a good example of how this can become quite stupid, I
recently created a port for a go application, the source tarball
includes the source of all dependencies, and everything is bundled in a
13MB executable (that only depends on libc.so and libthr.so).

With a port per dependency (ii), you sooner or later have to handle
conflicts between dependencies (port A needs foo-1.0.0 but port B needs
foo-2.0.0) and it can get tricky.

I only have experience with programming with Ruby as a language that has
similar problem.  I ended at only installing system tools using the
FreeBSD ports (e.g. puppet, vagrant, passenger), and for applications I
actually use, I just grab the source, and use bundler to gather all
dependencies as the user running the software, therefore I end up having
something similar to (i) without using the port system.

My weak Windows development experience learned me to put all dll of an
application in the application directory.  If it's still a good advice,
I guess that each application should have it's copy of all it's
dependencies, and therefore each port should install a bundle of all
what is required by it.



Another problem with nugets packages is that you only get binaries,
right?  That means that is something goes really wrong, there is no way
to audit the source code of what led to disaster.  The problem is
similar with the few Java projects I gave a look at.  My feeling is that
this is even worst :-(  Ruby being interpreted, there is no such
problems.

I am not enough involved in Java nor .Net to think about mitigations of
this issue.

-- 
Romain Tartière <romain at FreeBSD.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-mono/attachments/20170902/d197f942/attachment.sig>