Conflict on very first port (xorg) on rpi3

Fri May 15 19:33:08 UTC 2020

[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.
> 
> 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.)

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.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)