Date: Fri, 15 May 2020 14:24:35 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: FreeBSD ports <freebsd-ports@freebsd.org> Subject: Re: Conflict on very first port (xorg) on rpi3 Message-ID: <6C824795-DF23-4F5C-BF19-256177448183@yahoo.com> In-Reply-To: <20200515200358.GA54521@www.zefox.net> 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> <E0670AB1-42E5-4A01-87AE-0C671CC5CEB0@yahoo.com> <20200515200358.GA54521@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-May-15, at 13:03, bob prohaska <fbsd at www.zefox.net> 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 <marklmi at yahoo.com> wrote: >>>=20 >>> On 2020-May-15, at 11:05, bob prohaska <fbsd at www.zefox.net> = 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6C824795-DF23-4F5C-BF19-256177448183>