Conflict on very first port (xorg) on rpi3
bob prohaska
fbsd at www.zefox.net
Fri May 15 20:04:02 UTC 2020
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.]
>
> On 2020-May-15, at 11:59, Mark Millard <marklmi at yahoo.com> wrote:
> >
> > On 2020-May-15, at 11:05, bob prohaska <fbsd at www.zefox.net> wrote:
> >
> >> 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:
> >>>>>
> >>>>> Some building and isntalling had to occur prior to the
> >>>>> textproc/py-sphinx18 build attempt, possibly from
> >>>>> prior session(s) of building and installing.
> >>>>>
> >>>>>
> >>>>
> >>>> 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?
> >>>>
> >>>>> 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.
> >>>>>
> >>>>> textproc/py-sphinx has been around longer and has
> >>>>> 142 ports that require it. I'll not list them.
> >>>>>
> >>>>>
> >>>>> textproc/py-sphinx18/Makefile lists:
> >>>>>
> >>>>> CONFLICTS_INSTALL= py*-sphinx
> >>>>>
> >>>>> textproc/py-sphinx/Makefile lists:
> >>>>>
> >>>>> CONFLICTS_INSTALL= py*-sphinx18
> >>>>>
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>>
> >>>>> The conflict is real and limits what combinations
> >>>>> of ports you may have installed at the same time.
> >>>>
> >>>> I'll try deinstalling the conflicting port and hope
> >>>> it won't be required later....
> >>>
> >>> It seems that just devel/llvm80 is pulling sphinx18 when building
> >>> x11/xorg.
> >>>
> >>> Try disabling DOCS option on devel/llvm80 for now.
> >>>
> >>> I've opened a PR to track this issue:
> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246487
> >>>
> >>
> >> Wish I'd known it was only the DOCS option! Too late now,
> >> sphinx18 is deinstalled and llvm80 is building.
> >
> > 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 .
> >
> > 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.
Sorry, I mis-wrote. What you're describing is what I did.....
> >
> > 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.
>
> I did not trace down other dependencies but now
> looking a little (leaving options at defaults):
>
> 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.)
>
> Thus the sequence for default options may need
> to be something like:
>
> *) Starting without textproc/py-sphinx18
> installed
>
> 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.)
>
> B) uninstall textproc/py-sphinx so that
> textproc/py-sphinx18 can be built and
> installed
>
> C) build textproc/py-shpyinx18 and devel/llvm80
> and install devel/llvm80 ( py-sphinx18 can
> be via indirection through devel/llvm80 )
>
> D) uninstall textproc/py-sphinx18 so that
> either textproc/py-sphinx* can be installed
> if needed
>
> E) build xorg.
>
> (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.)
>
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.
> Of course, figuring out options to change
> the status of also may avoid having some
> of the dependencies and so avoid some
> conflicts.
>
> >> 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
> >> it could be done by hand, but that promises to be tedious.
> >
> > 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.
> >
> > If one is familiar enough to see potential
> > conflicts in lists of dependencies there are
> > the makefile targets:
> >
> > run-depends-list, build-depends-list
> > Print a list of all the compile and run
> > dependencies, and dependencies of those
> > dependencies, by port directory.
> >
> > all-depends-list Print a list of all dependencies for the port.
> >
> > 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.
> >
> > (but no "all" variant for pretty-print-* ?).
> > What is listed would depend on the options
> > specified.
>
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...
Thanks for writing!
bob prohaska
>
More information about the freebsd-ports
mailing list