Update on porting mono 5
David Naylor
naylor.b.david at gmail.com
Tue Sep 5 19:06:16 UTC 2017
On Saturday, 2 September 2017 11:03:59 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.
>
> Yeah, it's a problem that is broader and broader… and for which I don't
> think a universal solution works :-/
At a minimum, any nuget package that contains a native (i.e. compiled) portion
needs to be a Port.
> 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.
I think we can already handle that (see all the Qt ports). I'm not sure what
currently happens when A depends on B and C but B and C depend on different
versions of D. Does .NET just use the latest version of D?
> 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.
In my ideal situation all dlls will be installed in the GAC (or just linked to
where they are installed). If I read this [1] correctly, Debian advocates for
all dlls to be registered in the GAC.
> 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.
>
> I am not enough involved in Java nor .Net to think about mitigations of
> this issue.
This is my primary concern, how does one take control when each port manages
its own private dependencies.
[1] https://pkg-mono.alioth.debian.org/cli-policy/
-------------- 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/b2b21ac4/attachment.sig>
More information about the freebsd-mono
mailing list