Update on porting mono 5

[Robert Alegrid]

I apologize in advance if I formatted this message incorrectly or addressed it
incorrectly. This is the first time I'm posting to a mailing list, so I have no
real idea how I should be doing it.

I also just program as a hobby (and mostly on Windows at that), so that should
be taken in consideration as well.

On Saturday, 2 September 2017 7:03 PM, Romain Tartière wrote:
>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.  
It's possible for NuGet to use a local directory as a feed:
  https://docs.microsoft.com/en-us/nuget/hosting-packages/local-feeds
If you add the local feed earlier in the list of sources, it should pick up your
locally built packages instead of fetching it from the internet.

NuGet also maintains a cache of packages that it uses to restore from when it
doesn't have an internet connection to work with.

>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.
When building a prgram, you can save 
You're going to end up with a lot of duplication either way, given how assembly
locations are resolved:
  http://www.mono-project.com/docs/advanced/assemblies-and-the-gac/

>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.
Aside from a few special assemblies which live in the GAC, yes, that's basically
what you're supposed to do.

>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.
NuGet packages have in their manifest a field to specify where the source code
lives. However, since it's optional and is just a URL to the repository, it
probably doesn't help much for this use case.

Regards,
Robert Alegrid