From owner-freebsd-ruby@freebsd.org Sat Jan 25 22:04:43 2020 Return-Path: Delivered-To: freebsd-ruby@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DD8BB1FCB4F for ; Sat, 25 Jan 2020 22:04:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 484qmq5bGNz49R9 for ; Sat, 25 Jan 2020 22:04:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id BDB651FCB4E; Sat, 25 Jan 2020 22:04:43 +0000 (UTC) Delivered-To: ruby@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BC4321FCB4D for ; Sat, 25 Jan 2020 22:04:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 484qmq4Q6wz49R8 for ; Sat, 25 Jan 2020 22:04:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 930ADF0B0 for ; Sat, 25 Jan 2020 22:04:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 00PM4hVk076533 for ; Sat, 25 Jan 2020 22:04:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 00PM4hEs076532 for ruby@FreeBSD.org; Sat, 25 Jan 2020 22:04:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ruby@FreeBSD.org Subject: [Bug 240006] portmaster fails to build security/rubygem-acme-client: wrong order of installing requisite packages Date: Sat, 25 Jan 2020 22:04:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch, needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: se@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Works As Intended X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: se@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ruby@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FreeBSD-specific Ruby discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 22:04:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240006 Stefan Esser changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Works As Intended Status|Open |Closed --- Comment #8 from Stefan Esser --- Sorry for the late reply - apparently I do no longer get a notification by = mail when a PR is assigned to me. The information given by Walter Schwarzenfeld in Comment 7 is correct: Some ports have dependencies that are declared as run dependencies, but whi= ch are in fact required to install a port. This is possible in the "plain" por= ts system, since it implements recursion into run dependencies before installi= ng the port being requested. I.e. the building and installation of run dependencies is injected between building and installing the requested port= . I consider this an artefact of the implementation of the ports system in "mak= e", which cannot provide a different order: when the requested port has been installed the trigger for the installation of run dependencies is lost - if= you interrupt the process at that time, the requested port has been installed a= nd the missing run dependencies will be ignored. Portmaster processes always just one port from begin to end, it knows to up= date or install build dependencies before the port needing them, run dependencies afterwards, and it will detect missing run dependencies even if the build process is interrupted between installation of the port and its run dependencies. A different treatment of run dependencies in portmaster is possible, but wi= ll lead to dependency cycles, since run dependencies may themselves depend on = the port being worked being installed. If all run dependencies were treated like build dependencies, then these cycles will prevent building of either of th= em. Those ports that need run dependencies being available before the port depending on them has been installed have to declare them as build dependencies. If they are required for the build process to finish besides being run dependencies, then they need to be declared as both build and run dependencies. That the plain ports system does not require them to be declared as build dependencies is caused by the tool used (make) which does not support a different order than is implemented, but that does not set a precedent for portmaster, IMHO. Therefore, I'm going to close this PR - the fix is in the individual port t= hat lacks a RUN_DEPENDS declaration. --=20 You are receiving this mail because: You are on the CC list for the bug.=