From owner-freebsd-mono@freebsd.org Fri Sep 8 00:36:22 2017 Return-Path: Delivered-To: freebsd-mono@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62D5EE1B11C for ; Fri, 8 Sep 2017 00:36:22 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90DB9833EC; Fri, 8 Sep 2017 00:36:21 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x233.google.com with SMTP id l196so2450853lfl.1; Thu, 07 Sep 2017 17:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RMeD81Og5/EuiAUcZxFbpOwg1mf1pFbtMj5/pNkqXD4=; b=bod3soneUJ5wMAFIcw2cN7KuTV5YWBhGxO4QYiKV1K7bU3UlFu2ArB3HIiJ41b6ZVF LvFyH1tGTnRLjZUYUsTbDL7odSagqS3592KJHHTjDxydiHyOsC+sfIsAnsAjypb1Gpif gvLjMbQTl4zBUHHGSzosPN/844SwNsDnAhbRwHQf/GLAdtfq3whwdz2yk1dJ8eQO7kbB isA2MrTX3fzdcK7gmxjvCUECeCb+l9u/8J3zvByy3MLVUYOWDSL+VJIs+3nWr6GrOPbO l07l0vj5IJSb2eHNIlhnPs4eQYyc0QsEBCpFKIHlrO7UO5ehiQXvexnHCGIEN376Pnh4 aQkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RMeD81Og5/EuiAUcZxFbpOwg1mf1pFbtMj5/pNkqXD4=; b=i6MGtUCxD4T6LZEReZ27ngW32BkY6Et5xBv9lRVV/6ZewMv2bMmbKZn0ixzfQm5Bqu 9ehMqtgQ1L0WFd41wWM31Emo/QkHAXeq9XireEPEudx9T/oDbzdseKWEO9cHZjitsOVc mcomK5MT4lLwV8VkdYyL1v78/gJKWX0cEOCKReyePVw8/9+ZiRLChzJN/41rY2gqSNWh 1wwaoi0ZWkNcUy0ZFrmb7ZnUJvj53/YTKgUs1boocpPvnymlzBO+I3D7Zl3vs9b8RsM9 jdBxUCQTQZnG40hiznlxCEpPkRK4asWJSdgMHnvD9XRGyeeYR+Rt07GIEHUVrqVTy4aY l6iQ== X-Gm-Message-State: AHPjjUggvO2RL1J2R5QTJgmQ3IZNSjNTQA7VV8D2glhYisNdiHJoqV8q 8AD6smhBPPAOiSg2vMFFDlyBUtwt+moa X-Google-Smtp-Source: AOwi7QA22F8vibeSUuwVqaz/645t6TYkfSeRci+SmsMCrwDP3KEaIyFjzS+BaJ2p6yGTdkivXNrEqZkvRjlgyVjS69M= X-Received: by 10.25.19.197 with SMTP id 66mr275573lft.221.1504830978540; Thu, 07 Sep 2017 17:36:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Thu, 7 Sep 2017 17:36:17 -0700 (PDT) In-Reply-To: <2223962.JDsoWRiPl4@dragon.local> References: <17078253.u2dgjZK1Z6@dragon.local> <1557586.GGzvBQ0jK6@dragon.local> <2223962.JDsoWRiPl4@dragon.local> From: Russell Haley Date: Thu, 7 Sep 2017 17:36:17 -0700 Message-ID: Subject: Re: Update on porting mono 5 To: David Naylor Cc: Freebsd-mono , Robert Alegrid , =?UTF-8?Q?Romain_Tarti=C3=A8re?= Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-mono@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Mono and C# applications on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 00:36:22 -0000 On Thu, Sep 7, 2017 at 11:09 AM, David Naylor wrote: > On Tuesday, 5 September 2017 13:09:14 Russell Haley wrote: >> On Tue, Sep 5, 2017 at 12:25 PM, David Naylor > wrote: >> > On Saturday, 2 September 2017 07:40:28 Russell Haley wrote: >> >> On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid >> >> 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