Date: Tue, 5 Sep 2017 13:09:14 -0700 From: Russell Haley <russ.haley@gmail.com> To: David Naylor <naylor.b.david@gmail.com> Cc: Freebsd-mono <freebsd-mono@freebsd.org>, Robert Alegrid <eralegrid@hotmail.com>, =?UTF-8?Q?Romain_Tarti=C3=A8re?= <romain@freebsd.org> Subject: Re: Update on porting mono 5 Message-ID: <CABx9NuR6knOHfGEwZLvDZcTMn8e0TR5uscjh52DY1yq1-ujybQ@mail.gmail.com> In-Reply-To: <1557586.GGzvBQ0jK6@dragon.local> References: <17078253.u2dgjZK1Z6@dragon.local> <RO1P15201MB218761CDE84B83E1DF349DB8A8930@RO1P15201MB2187.LAMP152.PROD.OUTLOOK.COM> <CABx9NuSCoo_rEJdtZvSogaPrLs3FqfgmSchn56_RKkVaKc9XHQ@mail.gmail.com> <1557586.GGzvBQ0jK6@dragon.local>
next in thread | previous in thread | raw e-mail | index | archive | help
* I apologize for being lazy and linking to stack exchange answers. In a perfect world I would go and look this stuff up in the Nuget documentation. It leaves open the possibility of miss-interpretation (by me) and possible wrong answers. On Tue, Sep 5, 2017 at 12:25 PM, David Naylor <naylor.b.david@gmail.com> wrote: > On Saturday, 2 September 2017 07:40:28 Russell Haley wrote: >> On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid <eralegrid@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. Agreed. A poor deployment strategy by the Mono team IMHO. > 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). My perspective is that the entire point of Nuget is allow a developer to intrinsically link his project to a binary file of a specific version and be confident that the package manager will always download and link to that version (see the answer here: https://stackoverflow.com/questions/19817378/is-it-possible-to-add-update-assemblies-to-the-gac-via-a-nuget-package.). If the developer *wants* to always use the latest version, that is something the developer can configure (see https://stackoverflow.com/questions/24765802/nuget-spec-dependencies-get-latest-version). Though I agree with your point, I don't agree that this is a Unix/Windows difference. There are plenty of packages and applications on Unix where the developer chose not to use the global version and "Library Hell" is a real thing that FreeBSD handles very manually by specifying the version in the port name (Lua is a great example having lua51, lua52 and lua53). Conversely, Windows spent a long time using the registry (shudder) and the GAC has existed since the inception of DotNet. For DotNet, the decision to move to per-installation libraries has been a conscious choice made irrespective of OS philosophy. >> 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? I made a quick look and perhaps I'm incorrect. Everything indicates that registering with the GAC needs to be done externally (i.e. via PowerShell. lolz). None the less, the GAC is a powerful tool that perhaps we could leverage (although it's availability on a system with no runtime is suspect!). >> 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. In my mind, all the build tools/build dependencies should be handled differently from the runtime dependencies. These binaries we are discussing are only used for bootstrapping if I understand correctly. Build items specified within the port that are only available as binaries from nuget should be downloaded into the "work" directory and discarded after the build is complete (via make clean). I would think this is true unless said binaries are also runtime requirements, but in that case I would think the runtime required copies should be built from source where possible. For What It's Worth, Russ
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABx9NuR6knOHfGEwZLvDZcTMn8e0TR5uscjh52DY1yq1-ujybQ>