Update on porting mono 5

[Russell Haley]

On Thu, Sep 7, 2017 at 11:09 AM, David Naylor <naylor.b.david at gmail.com> wrote:
> On Tuesday, 5 September 2017 13:09:14 Russell Haley wrote:
>> On Tue, Sep 5, 2017 at 12:25 PM, David Naylor <naylor.b.david at 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 at 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

Hi David,

TLDR; I agree with you, but since I typed out my thoughts, I'll add it
to the discussion...

A subtle but important distinction. Also, are all items available in
pkg built from source? If yes, does that mean pkg is a source or
binary download? (kaboom! My head explodes).

My attempt at clarity about what constitutes a runtime dependency:

First we should clarify what dependency means in this context. I think
what we are really meaning is *external* dependency. If the sources
(sigh, or binaries. I may come from Windows land, but it still makes
me sad...) are provided by the package itself and used during runtime,
it is NOT an external runtime dependency and should not be considered.
This may be splitting hairs though. What if a version of OpenSSL is
included as source and built by the applications build tools? Is it an
internal or external dependency? (kaboom!). Again, I think we could
(willfully) simplify this by saying "anything not built (or
downloaded) by the application build tool for use by the build tools
output" is an external dependency and of interest to the discussion.

In the end, I think you are correct in your assessment. Policy A
(external dependencies) is really what we are talking about now, but a
shift to a more granular view of a package may provide flexibility.
That flexibility may come at the potential cost of adding complexity
and uncertainty (i.e. allowing someone to change an 'internal
dependency' package would have consequences). One must ask though, if
the user really wants to start mucking with internal library versions,
that user should just build from source themselves. Is the ports tool
a general tool for users, or a source manager for developers (a la Git
or Sourceforge)? As always, applying requirements gathering practices
to a problem is probably wise: What is our use case for Ports?

Russ