On Tuesday, 5 September 2017 13:09:14 Russell Haley wrote: > On Tue, Sep 5, 2017 at 12:25 PM, David Naylor <naylor.b.da...@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 <eraleg...@hotmail.com> > >> 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.
I agree with the above - except how do we define a runtime dependency: a) If the dependency needs to be installed (i.e. `pkg add`) for the program to run; or b) The program needs the dependency's dll (even if it is bundled) to run I think the policy should be for (b) [but (a) for now due to practical issues]. Regards
signature.asc
Description: This is a digitally signed message part.
