Date: Tue, 18 Sep 2018 15:23:33 +0200 From: Stefan Esser <se@freebsd.org> To: Matthias Fechner <idefix@fechner.net> Cc: Ports FreeBSD <freebsd-ports@FreeBSD.org>, Mathieu Arnold <mat@FreeBSD.org> Subject: Re: RUN_DEPENDS and portmaster Message-ID: <04b678b6-c2b8-5f7e-651a-e1dc1fa2fe75@freebsd.org> In-Reply-To: <5fc230b9-809e-4501-7375-fe6f0dda2cd6@fechner.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?04b678b6-c2b8-5f7e-651a-e1dc1fa2fe75>