Committer needed for PR 208029

[Michelle Sullivan]

Jim Ohlstein wrote:
> Hello,
>
> On 4/6/16 12:39 PM, Mathieu Arnold wrote:
>> +--On 6 avril 2016 12:00:47 -0400 Jim Ohlstein <jim at ohlste.in> wrote:
>> | Hello,
>> |
>> |> On Apr 6, 2016, at 11:37 AM, Mathieu Arnold <mat at FreeBSD.org> wrote:
>> |>
>> |> +--On 6 avril 2016 10:06:41 -0400 Jim Ohlstein <jim at ohlste.in> wrote:
>> |> | Hello,
>> |> |
>> |> | On 4/6/16 12:44 AM, Kurt Jaeger wrote:
>> |> |> Hi!
>> |> |>
>> |> |>> Actually, I just noticed (when compiling the port), that the 
>> Makefile
>> |> |>> now says:
>> |> |>>
>> |> |>> WITH_OPENSSL_PORT=yes
>> |> |>
>> |> |> Yes, sorry, my fault. Fixed, and as suggested by mat: It is
>> |> |> now as IGNORE with a message explaining how to do it for 9.x.
>> |> |>
>> |> |
>> |> | This is much ado about nothing. The "WITH_OPENSSL_PORT" option 
>> is there
>> |> | for just this purpose and is used in many ports.
>> |>
>> |> No, the WITH_OPENSSL_PORT knob is a global one, and must not be 
>> used in
>> |> ports makefiles.  The fact is, there are ports using it, true, it 
>> does
>> |> not mean it is the right thing to do.
>> |>
>> |
>> | Then there are many ports being committed incorrectly, as well as, no
>> | doubt, many *official* packages.
>> |
>> | I really have no dog in this fight. I use it globally and build all 
>> of my
>> | own packages with poudriere, but either it shouldn't be there at 
>> all, or
>> | it should be ok to use. Having it available as an option to porters 
>> and
>> | then saying it shouldn't be used seems a bit silly.
>>
>> Well, it is not available for the porters as it is a global 
>> directive, they
>> use it anyway.
>>
>> Anyway, like I said, working on it.
>>
>
> Maybe an edit to portlint is in order. That way they might know. As of 
> now, portlint does not so much as emit a warning.
>
> I don't entirely disagree with the premise that all ports that require 
> OpenSSL should be built against the version in ports. As I said, I do 
> it and it also makes port maintenance simpler. However, as long as it 
> is actually an option, as it is now, then it should be availed when 
> desired.
I don't agree or disagree for what it's worth... What I do say though is 
where ever possible all ports should be compiled against one version.. 
of course GSSAPI support is a 'special case' in point that might have to 
break that rule of thumb.

>
> Further down the road (but not all that far) I foresee other, perhaps 
> bigger problems if using this strategy. OpenSSL 1.1.0 is in beta and 
> will be released within the next month or two. It is not completely 
> backward compatible. 

100% there...!

> At some point it will become the official ports version and/or two 
> versions will need to be maintained in ports, 1.0.2 (LTS until 2019) 
> and 1.1.x. This will create the problem of some/many ports not 
> building against 1.1.x and some ports or port options _requiring_ 
> 1.1.x. Assuming 1.1.x is the main OpenSSL in ports, there will be 
> ports that would build properly against OpenSSL in base (but cannot be 
> built that way if using the ports version is mandated), and do not 
> compile against OpenSSL 1.1.x. Most can no doubt be patched, but 
> waiting for upstream providers to do so may be problematic, and many 
> porters lack the skills.
>
Personally I'm surprised there is not more than one major version of 
openssl in the ports tree already.. perhaps there should be...

-- 
Michelle Sullivan
http://www.mhix.org/