Re: Fix www/ocaml-cohttp build errors

[Greg Troxel <gdt%lexort.com@localhost>]

Jaap Boender <jaapb%kerguelen.org@localhost> writes:

> On Saturday, 27 June 2020 14:43:10 CEST Greg Troxel wrote:
>> Could you:
>> 
>>   explain how many packages depend on the packages you are changing
>> 
>>   explain what's really going on.   "Fix build error" does not describe
>>   the change.
>> 
>>   provide the commit message you would use
>
> The patch switches some options in net/ocaml-conduit and devel/ocaml-logs to 
> being suggested where they weren't before, which fixes some build errors in 
> www/ocaml-cohttp (that needs those packages to be enabled); I don't think it 
> can do any harm.

By explain, I meant that it seems there is some build failure (in which
package?), but why, and as you say, what are the rules?    I don't know
what these options do, why they are options, what the right default
choice is for users.  I also don't understand why, if the option is
disabled and something important breaks, why it's even an option.   Or,
the depending package should check the option and set BROKEN.
>
> As an aside, I'm not sure if this dependency occurs all the time in cohttp, or 
> if it only triggers if certain options are enabled in www/ocaml-cohttp; in 
> general, what is the policy here? Can we specify dependencies on packages 
> where certain options should be enabled, or is the idea to just enable 
> everything that might potentially be needed by any dependency?

There is no mechanisms to ask that a dependency have an option.   The
two strategies are basically:

  Enable options by default if the benefit to users outweighs the pain.
  In the extreme, don't make them options.

  if a package needs a dep to have an option, test for that and fail
  with a useful BROKEN message


Really doing that in the large scale is too much for the branch (but a
great thing to revisit immediately after), so the question is how many
packages (directly and transitively) depend on the ones to be changed,
and what the impact of those options are.

It's also useful to report if all those depending packages, not just the
one being fixed, still build with the change.


(I don't mean to say this change shouldn't happen.  I just like what is
effectively a change control board to have a good explanation of why a
proposed change is 1) needed and 2) safe.)