Date: Wed, 27 Mar 2019 07:45:45 +0100 From: Stefan Esser <se@freebsd.org> To: bob prohaska <fbsd@www.zefox.net>, "Bradley T. Hughes" <bhughes@freebsd.org> Cc: freebsd-ports@freebsd.org, Jonathan Chen <jonc@chen.org.nz> Subject: Re: Can't compile www/node on rpi2 Message-ID: <fb5ce440-9201-4094-fd97-d7cb7439ac1f@freebsd.org> In-Reply-To: <20190327014647.GB90710@www.zefox.net> References: <20190323213940.GA74509@www.zefox.net> <c2fd7325-ad2e-afbb-4f5b-3223e530d6d3@freebsd.org> <20190326021459.GA87373@www.zefox.net> <b8fcb348-6dd6-38b0-f1a3-fa84214bc7b3@freebsd.org> <CAJuc1zP%2Bq6bTndL9ShCH=0wfdS5TrbWOqaAwEJNa97dM%2B40wUw@mail.gmail.com> <8be4cab4-febb-17d6-fa6c-422fb8085b78@freebsd.org> <20190327014647.GB90710@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 27.03.19 um 02:46 schrieb bob prohaska: >> All the >>> port-management tools in ports-mgmt assume this, and build >>> port-dependancies as required. When building ports, it is always best >>> to use one of the build-tools (ie: poudriere, synth , portmaster) >>> instead of by hand. >> > I've played a little with portmaster, and it seemed more prone to stopping > unintentionally than a simple "make -DBATCH" in the port directory. IIRC, > it always stopped on stale but installed dependencies. Perhaps I'm doing > somthing dumb, but I couldn't figure out what it was. Could it merely be > the fact that I'm using a Raspberry Pi 2 or 3? Could you provide me with traces of portmaster runs for cases where it did not upgrade stale dependencies? The dependency resolution and build strategy of portmaster scans all ports for potential upgrades and ought to upgrade dependencies first, even if the currently installed versions satisfy version requirements stated in a dependency. Portmaster should only stop if a dependency cannot be upgraded (and it does this even if an older version is installed that might be sufficient for the build attempted) or if it detects conflicts that cannot be resolved without user intervention. There have been a number of problems in the ports collection recently, which lead to problems for port management tools other than poudriere. E.g. due to the removal of FLAVORS from ports that could be built with either qt4 or qt5, which was not accompanied by entries in MOVED that provide a hint about the prior category/port@qt5 now just being category/port again ... I'd like to get such cases detected and correctly dealt with in portmaster, but each additional special case will slow down general processing due to tests that take time but fail in 99,99% of cases. And they consume my time due to the need to develop and test work-arounds for such cases ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fb5ce440-9201-4094-fd97-d7cb7439ac1f>