Update on porting mono 5

[David Naylor]

On Saturday, 2 September 2017 07:40:28 Russell Haley wrote:
> On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid <eralegrid at hotmail.com> 
wrote:
> >>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.
> 
> Is this coming up because of the use of Nuget during the build process
> or is it because of general concern for the user?

The first issue is a practical one: with ports now requiring tens of nuget 
packages (and lock files generated by nuget - so we cannot cheat) it is 
becoming an issue with porting.  

The second issue is more a philosophical one around concern for the user.  The 
discussion below covers this concern and doesn't change the immediate plans 
for handling nuget packages (as bundled dependencies).  

> As a professional DotNet developer, I agree with Mr. Alegrid for the
> most part. Nuget is designed as a binary tool because DotNet is a
> binary based system. It comes from a user mindset, not an opensource
> mindset. Because of that, I question why we are having this
> discussion. Is it not the decision of the user/developer how they
> would like to use their package manager?  Also, it is their choice if
> they prefer to use sources. I sometimes do both. Stable packages from
> Nuget and others from source.

The question here is how easy is it for the developer to change the binaries 
they consume?  

A good way to illustrate the problem is the Heart Bleed bug in OpenSSL.  
Currently on FreeBSD the libopenssl.so file is centrally accessible, so to fix 
the bug just requires fixing the centrally stored libopenssl.so file.  
However, if all programs that used libopenssl.so had their own local copy (say 
statically compiled, or otherwise) the fix would be a headache.  In the land 
of Ports, we would need to patch (or wait for an update of) every single port 
that used OpenSSL.  

This is obviously a problematic situation to be in.  Philosophically it is one 
of the differences between Windows (everyone bundles all their dependencies) 
and Unix [1] (all dependencies are centrally available).  

> Nuget is designed for local, per project resources. It is particularly
> effective when developing across many developers as it will go and get
> the packages for you automatically at build time (wicked cool feature,
> which seamlessly mixes source with binary distribution). Items that
> are supposed to live system wide are to be stored in the General
> Assembly Cache (GAC) and should be designed to be put there. You can
> get Nuget to drop things in the GAC but have not used this feature.
> The GAC is designed around large scale software deployments which,
> sadly, I don't think will ever apply to mono on FreeBSD.

In a limited sense, nuget is redundant on FreeBSD thanks to the Ports 
Collection and pkg - but I do see the need on Windows and more generally in 
the .NET ecosystem.  

Do you perhaps have any links that detail how nuget can store dlls in the GAC?

> Worrying about per-port repositories for Nuget is not a thing because
> the manifest within DotNet applications decides what runtime version
> of the assembly to use at build time so it is necessarily per-port.
> Also, DotNet can have hard or soft links (I forget the terminology) to
> required assemblies in the sense they can specify to use any version
> or a specific version, and can specify if the assemblies require to be
> signed (i.e. verified by the authors credentials against a trusted
> list). The GAC handles versioning for system level assemblies and if
> you overwrite a required version in your local repository it's a
> development error that you need to sort yourself.

Unfortunately, we do need to worry about per ports dependencies.  In the 
practical case it is around the need to download the nuget packages within the 
Ports Collections framework (so we get security protection, etc), before the 
build phase.  Ports are not allowed interest access during build.  

Regards

[1] I know PC-BSD, for a while at least, also bundles all dependencies within 
a PBI?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freebsd.org/pipermail/freebsd-mono/attachments/20170905/d9545e38/attachment.sig>