From owner-freebsd-ports@freebsd.org Fri May 15 21:24:46 2020 Return-Path: Delivered-To: freebsd-ports@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 04F452DA5E1 for ; Fri, 15 May 2020 21:24:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49P1dQ5x2Tz4Tv5 for ; Fri, 15 May 2020 21:24:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Pk4LC6IVM1k3.16MarbvaiVEddBiivSpUnZWUeY8yeg7MVna62Q9RGiyw6n_4EN 1bLEfgNfXAzILRfqZDajY9AMm_V19NcK_aK8_F.sJztUK9D.bqgqV_R3VgazujtovH6u.LBFEZO. zj4OtXvj3UfC.xZSYwSJYuMekQU9yX_K_OnrUt5PHdXTqT4PIBLplpoRgE86wM1YGBtq7PZJHBod suv3r7K2X2B8eLmJxPD6h2g1DVUcWg0IyOAovQmt08vKgiKbNEfLYLucfMfdv80csnnlBrNMCbS4 rIq1IHLRqv732s1P3R9QWeEcaD7_nZ5qXrkbcjd_FsGMeDzWWW7VNRXdbY._eA0GUMUBxWL0IcLV cEmuz88lfG5fy4ncqh8WLGcdHioAuPmvqjnFCR5ziOciko0w2yVV8hF_wkYF9oDR69rSpotCx75u X5wbPRKqXlCnzbamdQccpPNxWMGcZxHQTuJENG32OskA1iJ9OhrPoSMesMEZ_ugNqM80oG5IpyP6 WP_rP.ALQkLknrDJVxwLGAFN4t2wXMORrCZs3.nWBh0wJw7.Pc3npM3RqnJEq2DMH0w8rrZM2.xx VsFk1ZTZ1SkKwaajVp9ZfDYBtNI9jacRLyEPnNnpM.BiFExjEaCRYXJoAaU5bCZTZUJSIlu2.4Zx 2H.A5qIB4dxN6TJEJfzd0nGg8w8yQirlAR8ujfjKwtLpwkv1nIXKuo4YyzCI6rwUmYHfMmK7ccFU gA2gvUQKAU3_QjEhDKV6NlCuaJ_smkt2LT79L9YXmpGiI2zKX4b7H1zl8foHp_22wDrDKm_e_6hh VqpceQMLFruulExNtgEMUfrSVcbTShZ7Wu8p_EqTB1F8QO1xjsNRgNvBy4LsGITUXXyKuSnH4zHV 8SKT3aPGvMCZTFWRCqz5bNrpFHxUWwAaRT7ZeM2aQBxPEOkTOG5ueuM5jMFo89OcGGZLiq5NVgZG B4AVyCLSZ2EaolXDsTyfZX95_hh6E5UzlCe_0cfp8P2QmDEMwYbkBL2X4ziSv7IdGW2eI1QEkqpF IAG9QgJ5u7HQn.HEM51vjLsx5MobP_ozyxnD1cViw..4.G8r.lcoVm.13L2dR7Ki3ZN.m7OVOdVB Eu.pJVG7iP2ci9S.vzdaJLXA0tZsLeLgNaGlctNpB2cmfFaEM2aVh06WB894UKPZMygx9EGqOprk 9XQe2.GWynkk0Kp0qvbDKaiJxdBRZ0r6Csg0QN2Ie2iZ4tqtL8W1njyCBT.24q7rSheq.6Lk4_9s GsggAqOvELiZUZU2cw6.nNH481SEfuse2A0CyiN2Pb7zv7K28_.R6VhFygcjPScQ1JKxMPtjWOkl tBIDYEn57OTMMwFMFDs.7pUIc3UwMqNnot_XA_g3EZjRCSWsYJAvtjvVwIytyw4eSi3iIn.QYUHe 9SemZRHZ7NmCZI3MJxUJOrtCZvQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 May 2020 21:24:40 +0000 Received: by smtp421.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9a23ccf7d7242987b0b8965f9b7ffcfb; Fri, 15 May 2020 21:24:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Conflict on very first port (xorg) on rpi3 From: Mark Millard In-Reply-To: <20200515200358.GA54521@www.zefox.net> Date: Fri, 15 May 2020 14:24:35 -0700 Cc: FreeBSD ports Content-Transfer-Encoding: quoted-printable Message-Id: <6C824795-DF23-4F5C-BF19-256177448183@yahoo.com> References: <4961F458-26EF-447F-8033-B00FA720C58F.ref@yahoo.com> <4961F458-26EF-447F-8033-B00FA720C58F@yahoo.com> <20200515151922.GC51382@www.zefox.net> <20200515164921.6zyiorfgnqhf5nls@t480.local> <20200515180554.GD51382@www.zefox.net> <35F4EC61-AC55-4FA4-89D4-7742E449CC8A@yahoo.com> <20200515200358.GA54521@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49P1dQ5x2Tz4Tv5 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.41 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.951,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (1.83), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; NEURAL_SPAM_MEDIUM(0.04)[0.040,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[205.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[205.69.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 21:24:47 -0000 On 2020-May-15, at 13:03, bob prohaska wrote: > On Fri, May 15, 2020 at 12:33:02PM -0700, Mark Millard wrote: >> [Gack: devel/cmake needs devel/py-sphinx by default >> and devel/llvm80 needs both devel/cmake and >> devel/py-pshinx18 by default.] >>=20 >> On 2020-May-15, at 11:59, Mark Millard wrote: >>>=20 >>> On 2020-May-15, at 11:05, bob prohaska = wrote: >>>=20 >>>> On Fri, May 15, 2020 at 01:49:21PM -0300, Danilo G. Baio wrote: >>>>> On Fri, May 15, 2020 at 08:19:22AM -0700, bob prohaska wrote: >>>>>> On Fri, May 15, 2020 at 12:33:10AM -0700, Mark Millard via = freebsd-ports wrote: >>>>>>>=20 >>>>>>> Some building and isntalling had to occur prior to the >>>>>>> textproc/py-sphinx18 build attempt, possibly from >>>>>>> prior session(s) of building and installing. >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> In this case x11/xorg was the first port attempted in a new >>>>>> ports tree. The only "prior sessions" would have been within >>>>>> the dependencies of x11/xorg. Is that resolvable by poudriere? >>>>>>=20 >>>>>>> textproc/py-sphinx18 is new as of 2020-May-11. >>>>>>> The devel/llvm[16789]0 ports require textproc/py-sphinx18 . >>>>>>> Only about 26 ports require textproc/py-sphinx18 but >>>>>>> I'll not list the others. >>>>>>>=20 >>>>>>> textproc/py-sphinx has been around longer and has >>>>>>> 142 ports that require it. I'll not list them. >>>>>>>=20 >>>>>>>=20 >>>>>>> textproc/py-sphinx18/Makefile lists: >>>>>>>=20 >>>>>>> CONFLICTS_INSTALL=3D py*-sphinx >>>>>>>=20 >>>>>>> textproc/py-sphinx/Makefile lists: >>>>>>>=20 >>>>>>> CONFLICTS_INSTALL=3D py*-sphinx18 >>>>>>>=20 >>>>>>>=20 >>>>>>> So, for example, indirectly the devel/llvm[16789]0 >>>>>>> ports conflict with at least 142 other ports because >>>>>>> of the textproc/py-sphinx* difference in requirements. >>>>>>>=20 >>>>>>>=20 >>>>>>> The conflict is real and limits what combinations >>>>>>> of ports you may have installed at the same time. >>>>>>=20 >>>>>> I'll try deinstalling the conflicting port and hope >>>>>> it won't be required later.... >>>>>=20 >>>>> It seems that just devel/llvm80 is pulling sphinx18 when building >>>>> x11/xorg. >>>>>=20 >>>>> Try disabling DOCS option on devel/llvm80 for now. >>>>>=20 >>>>> I've opened a PR to track this issue: >>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246487 >>>>>=20 >>>>=20 >>>> Wish I'd known it was only the DOCS option! Too late now, >>>> sphinx18 is deinstalled and llvm80 is building. >>>=20 >>> What? llvm80 requires textproc/py-sphinx18 (when >>> the options cause such), not textproc/py-sphinx . >>> Deleting textproc/py-sphinx18 and building >>> devel/llvm80 will try to rebuild/install >>> textproc/py-sphinx18 unless the options are >>> set to avoid needing textproc/py-sphinx18 . >>>=20 >>> To build devel/llvm80 it would be >>> textproc/py-sphinx that would be deinstalled first >>> so that textproc/py-sphinx18 could be built and >>> installed during the build. >=20 > Sorry, I mis-wrote. What you're describing is what I did..... Ahh. >>>=20 >>> After devel/llvm80 is installed, textproc/py-sphinx18 >>> would be uninstalled so that textproc/py-sphinx could >>> be built/installed when xorg is re-tried with llvm80 >>> already installed. >>=20 >> I did not trace down other dependencies but now >> looking a little (leaving options at defaults): >>=20 >> devel/cmake needs devel/py-sphinx by default >> and devel/llvm80 needs both devel/cmake and >> devel/py-pshinx18 by default. (xorg need not >> bein involved: just building devel/llvm[16789]0 >> has the issue.) >>=20 >> Thus the sequence for default options may need >> to be something like: >>=20 >> *) Starting without textproc/py-sphinx18 >> installed >>=20 >> A) build textproc/py-sphinx and devel/cmake >> and install devel/cmake ( py-sphinx can >> be via indirection through devel/cmake ) >> (cmake does not have a run-time dependency >> on textproc/py-sphinx as far as I can tell.) >>=20 >> B) uninstall textproc/py-sphinx so that >> textproc/py-sphinx18 can be built and >> installed >>=20 >> C) build textproc/py-shpyinx18 and devel/llvm80 >> and install devel/llvm80 ( py-sphinx18 can >> be via indirection through devel/llvm80 ) >>=20 >> D) uninstall textproc/py-sphinx18 so that >> either textproc/py-sphinx* can be installed >> if needed >>=20 >> E) build xorg. >>=20 >> (Since I use devel/poudriere-develto build >> packages and then install just packages for >> things that I run, I do not have to do such >> explicit conflict management for build-time >> conflicts.) >>=20 >=20 > A brief look at the man page for devel/poudriere suggests > that several GB of space will be required for each port > to be built; is that the case in practice? Seems like that > would lead to stupendous overhead for complex ports, like > browsers. Poudriere has tradeoffs. I'm only pointing out an issue it is designed to help avoid. In my context, being prepared for (having resources for) poudriere's tradeoffs was explicitly chosen and set up for. Do not take my references to dependency management as a claim that the choice in tradeoffs is not yours to make. I've used portmaster as my main ports-building-and-installing environment in the past, making different tradeoffs back then. I always managed to deal with the dependency issues and it was less machine-resources intensive than what I do now --by me managing details. I'm unsure what the proportional-to-number-of- ports-to-build judgment is tied to. It only runs so many jobs at once, and you can have that be one job. Separately, you can control the amount of parallelism in each job. (In effect, sort of like using -jN for buildworld buildkernel.) But that internal parallelism in a job does not lead to more chroot areas being live at the same time. However, ignoring the proportional-to-port-count point, there is more space involved overall. It normally does have a clean buildworld area involved (that need not match the host environment). The area can be separately built and then null mounted by poudriere. (I do this.) A similar point goes for null mounting a /usr/ports/ area. Also, the amount of storage for a job likely depends on the file system used. I'm odd in that I use UFS instead of ZFS everywhere, even machines with enough resources to well use ZFS without significant configuration changes (from defaults). There is how much is null-mounted vs. not. And so on. I'll not get into other details about that or other points about resource/cpu use. >> Of course, figuring out options to change >> the status of also may avoid having some >> of the dependencies and so avoid some >> conflicts. >>=20 >>>> This is probably a dumb question, but is there some way >>>> to learn at the outset what conflicts need to be worked >>>> around? Something like a "make conflicts" target? Seemingly=20 >>>> it could be done by hand, but that promises to be tedious.=20 >>>=20 >>> Not that will tell you what combinations of >>> options lead to what combinations of required >>> build or run prerequisites: That could be >>> a lot of combinations to cover. It is also >>> dependent on poudriere-like-building vs. not >>> for build prerequisites having conflicts >>> involved or not. >>>=20 >>> If one is familiar enough to see potential >>> conflicts in lists of dependencies there are >>> the makefile targets: >>>=20 >>> run-depends-list, build-depends-list >>> Print a list of all the compile and run >>> dependencies, and dependencies of those >>> dependencies, by port directory. >>>=20 >>> all-depends-list Print a list of all dependencies for the = port. >>>=20 >>> pretty-print-run-depends-list, pretty-print-build-depends-list >>> Print a list of all the compile and run >>> dependencies, and dependencies of those >>> dependencies, by port name and version. >>>=20 >>> (but no "all" variant for pretty-print-* ?). >>> What is listed would depend on the options >>> specified. >>=20 > It appears that simply deinstalling the existing port causing a > conflict is the best short-term approach. Can't solve the run-time > conflict issue that way, but it's a start... This works when the port is only needed at build time, not needed at run time. It is messier for conflicts in what is needed at run-time for the final configuration's intended use. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)