From owner-freebsd-ports@freebsd.org Tue Sep 18 13:23:44 2018 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 640D1109E2C6 for ; Tue, 18 Sep 2018 13:23:44 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3E7E7076E; Tue, 18 Sep 2018 13:23:43 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd32.aul.t-online.de (fwd32.aul.t-online.de [172.20.26.144]) by mailout04.t-online.de (Postfix) with SMTP id 5D5B4419E992; Tue, 18 Sep 2018 15:23:36 +0200 (CEST) Received: from Stefans-MBP-LAN.fritz.box (EAXp3sZTYhZt+jgkFHZydTUtDbsUpNudvIhUuCHG3o7KnUBI3L+Vj6QKmphokw5Zbt@[93.200.57.131]) by fwd32.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1g2FyY-0EoRLk0; Tue, 18 Sep 2018 15:23:34 +0200 Subject: Re: RUN_DEPENDS and portmaster To: Matthias Fechner References: <03c14234-538d-fd9f-0c33-22825f3ea91d@fechner.net> <20180910101655.uzyriuylsucz7u3y@ogg.in.absolight.net> <9cf4d06d-e49d-aede-ca8f-b9ad1e9f19af@fechner.net> <957c48fb-bad8-a481-1626-54be15e34993@freebsd.org> <5fc230b9-809e-4501-7375-fe6f0dda2cd6@fechner.net> From: Stefan Esser Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNKVN0ZWZhbiBFw59lciAoWWFob28hKSA8c3QuZXNzZXJAeWFob28uZGU+wsCWBBMBCgBA AhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AWIQSjceplnAvsyCtxUxNH67XvWv31RAUC WvLvqwUJCyUBEwAKCRBH67XvWv31REySCACc6vqcSFQCRyBRc2CV5ZBjbbnTy7VBoXbUS3/c 4Hn8I0YQ39q7//2z8vYsgLeM1mMXL4PUIU/0f0dBAFBLpxV7bntGzyCJls6SeGS/qcQKhqaI 6I7NcWg8OkIJIhUL6q238cS1ql9pU65fyHe0PP8JS08m81PDpX2/4wTE6h2jgYUy55eXRzoF MEjr1S8SSnidsBem27o7iWu9ltJsUtE86071iZlLzbuHv2nvucrjAV9cK9tHrxYT/YiY8QhT L48iWj2xIjLjg1ebmgIFZ2k881we/KTIoUugqOOR1gDSc4qwM8CA388cN3frjtl98CwhAT5T UV8tIDqri+/Z1AKwzsBNBFVxiRIBCACxI/aglzGVbnI6XHd0MTP05VK/fJub4hHdc+LQpz1M kVnCAhFbY9oecTB/togdKtfiloavjbFrb0nJhJnx57K+3SdSuu+znaQ4SlWiZOtXnkbpRWNU eMm+gtTDMSvloGAfr76RtFHskdDOLgXsHD70bKuMhlBxUCrSwGzHaD00q8iQPhJZ5itb3WPq z3B4IjiDAWTO2obD1wtAvSuHuUj/XJRsiKDKW3x13cfavkad81bZW4cpNwUv8XHLv/vaZPSA ly+hkY7NrDZydMMXVNQ7AJQufWuTJ0q7sImRcEZ5EIa98esJPey4O7C0vY405wjeyxpVZkpq ThDMurqtQFn1ABEBAAHCwHwEGAEKACYCGwwWIQSjceplnAvsyCtxUxNH67XvWv31RAUCWvLv qwUJCyUBGQAKCRBH67XvWv31RLnrB/9gzcRlpx71sDMosoZULWn7wysBJ/8AIEfIByRaHQe3 pn/KwE57pB+zFbbQqB7YzeZb7/UUgR4zU2ZbOcEfwDZcHUbj0B3fGRsS3t0uiLlAd8w0sBZb SxrqzjdpDjIbOZkxssqUmvrsN67UG1AFWH9aD24keBS7YjPBS8hLxPeYV+Xz6vUL8fRZje/Z JgiBMIwyj6g2lH/zkdnxBdC0iG1xxJOLTaghMMeQyCdH6ef8+VMyAlAJsMckbOTvx63tY8z7 DFcrnTJfbe1EziRilVsEaK8tTzJzhcTfos+f3eBYWEilxe5HzIhYKJeC7lmsSUcGwa6+9VRg a0ctmi9Z8OgX Cc: Ports FreeBSD , Mathieu Arnold Message-ID: <04b678b6-c2b8-5f7e-651a-e1dc1fa2fe75@freebsd.org> Date: Tue, 18 Sep 2018 15:23:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <5fc230b9-809e-4501-7375-fe6f0dda2cd6@fechner.net> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: EAXp3sZTYhZt+jgkFHZydTUtDbsUpNudvIhUuCHG3o7KnUBI3L+Vj6QKmphokw5Zbt X-TOI-MSGID: 113c256d-1d52-4299-bf93-da044ee12b58 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2018 13:23:44 -0000 Am 18.09.18 um 14:05 schrieb Matthias Fechner: > Dear Stefan, > > Am 17.09.2018 um 14:31 schrieb Stefan Esser: >> But the behavior of portmaster will not be changed. >> RUN_DEPENDS are dependencies required to run a port, not dependencies >> required to install a port. >> >> >> And I do not care whether bsd.port.mk treats RUN_DEPENDS as if they >> were INSTALL_DEPENDS (which do not exist). The fact that bsd.port.mk >> works in that way is due to the fact, that it generally executes sub >> processes in a depth first manner. Portmaster distinguishes build and >> run dependencies and makes sure, that build dependencies not only exist, >> but are updated before the ports they depend on, while bsd.port.mk will >> use any build dependency that satisfies the range requirements (if any) >> and does not upgrade existing but outdated (in the sense that an upgrade >> is available) dependencies. Portmaster will then upgrade any out-dated >> run dependencies (again if an upgrade is available, not only if it is >> strictly required). Thus portmaster guarantees, that a port is built >> with the latest available build tools, and that run dependency upgrades >> see the upgraded port that requires them, in case they depend on it. > > I fully understand you. > > Maybe it will be a good idea to phase portmaster out as it seems to be a > unmaintable beast? > > Maybe synth can replace it for users that are not used to poudriere? I have been using a portmaster-rewrite for many months, which is ready for release except for some performance tuning. (The portmaster in ports is not un-maintainable, but it's hard to modify a monolithic 4000 line shell script that uses global variables to pass state and recursive invocation of itself to provide local state when required.) The performance problems are caused by bad design of the FLAVOR feature, which ignored the requirements of tools like portmaster (I've written about this at length when FLAVOR support had been committed). Synth is a non-starter for me, since it is written in Ada and only available on i386/amd64. I have plans to implement the functionality of synth in portmaster (not really hard, since the complex parts are the logic that deals with moved ports and conflicts, while the actual port building is simple). Portmaster can already create packages without installing them (unless they are BUILD_DEPENDS of some later port, of course) and you can populate your local repository with portmaster. Different from poudriere or synth, portmaster adapts to the preferences of the user (and e.g. upgrades samba48 used by some port that specifies a dependency on samba46, if the system already has an outdated samba48 installed). Portmaster will use what's available on a system and does allow selective upgrades (keeping some ports at a back-level on purpose, but still upgrade other ports that depend on them), while a poudirere/pkg based upgrade will typically require all dependencies to exactly match what was present at the time the package was built (in a clean environment, not resembling the system the packages are going to be installed on). Both, portmaster and poudriere/pkg have their use-cases, and there is only a partial overlap. There are quite a number of portmaster users, and they use it since their use-cases are not well covered by other tools. The way the ports system handles installs (in that it installs RUN_DEPENDS before the port that needs them) is an artifact of the way Makefiles naturally work, i.e. of the tool the ports system is based on. I do not understand why you intend on having RUN_DEPENDS cause installation of dependencies before your port. If you need those dependencies before the port is installed, then they are not really run dependencies, but dependencies of your particular build process. Portmaster has worked for far more than a decade with >20,000 ports. I do not see that your single port that expects run dependencies to be available before the installation has completed is reasonable cause to change the way portmaster works with dependencies. It pre-dates the "new" ports framework by far, and it used to be common practice, that changes respect established practices. BTW: Your port-install target will not be run when installing from a package (or building a package) anyway. Portmaster will take care of providing the required dependencies, as will pkg. So what's the reasoning that this test in do-install is required at all? You already specify exact versions in the RUN_DEPENDS, which are checked by the ports framework. Portmaster will take care, that all these ports are re-built to the latest level (hopefully satisfying the version test) after gitlab-ce has been installed. If you use pkg, the test is performed at install time, too. Are there any PRs due to lack of that test? Regards, STefan