base components should always be default (Re: change in default openssl coming)

[Grzegorz Junka]

On 08/07/2016 23:59, Kevin Oberman wrote:
> On Fri, Jul 8, 2016 at 12:20 PM, Grzegorz Junka <list1 at gjunka.com> wrote:
>
>> On 08/07/2016 16:29, Mikhail T. wrote:
>>
>>> On 08.07.2016 02:26, Mathieu Arnold wrote:
>>>
>>>> During this summer (sometime in August I think) I will be changing the
>>>> default OpenSSL for the ports tree from the base system version to
>>>> security/openssl.
>>>>
>>> The short answer is "Why?!" The longer reaction is: "please don't".
>>>
>>> Certainly not without a lengthy and exhaustive discussion (or flame-war,
>>> if you will), which shall arrive at a consensus -- and, if it does not,
>>> then no change shall happen.
>>>
>>> Generally, we should be eating our own dog-food -- using base-provided
>>> components for everything by default where at all possible. If the base
>>> OpenSSL is in some way(s) deficient, well, that's an argument for
>>> updating the base. The base comes with not just the libraries, but withe
>>> accompanying header-files -- meaning, the developers are free to use
>>> those libraries. So the ports certainly should be doing just that.
>>>
>>>
>> The only reason I heard why base isn't updated with the proper package
>> from ports is because of security implications. Older versions are more
>> security-tested and therefore safer. If there is a vulnerability in the
>> base it's much more hassle to update the base than ports.
>>
>> I don't have my opinion and sometimes it's annoying to not be able to use
>> the base version, but putting everything into base is certainly an option
>> if only the process of updating the base was light and quick enough. Is it
>> like that now? Maybe with the incoming release cycle from FreeBSD-11?
>
> Not really, though it is an issue. The issue with OpenSSL (and other
> contributed code that is also part of ports) is that that the base is
> limited to being updated with major releases if ABI changes are involved.
> This keeps base well behind the current release and ports often require the
> newer version in ports. It also means Building some ports with the base
> system and some with the ports version leads to a chaotic situation where
> one library is linked to the port shareable and another to the base one.
> Then another port links to both of those libraries and that makes it
> non-runnable as rtld won't load an image if it requires two different
> versions of  shareable. Very awkward to clean up this mess. I know, having
> had to do so a couple of times.
>

Is anyone familiar how source-based Linux distros deal with this issue, 
e.g. Gentoo?

For me the most sane approach would be if pkg/ports didn't allow to 
install packages that mix versions of the same applications:

  - if there is a newer version installed from ports and one tries to 
install a package that depends on an older version from base, the base 
version is replaced with the ports version and the dependent ports 
re-installed (depending on options), or the operation is aborted.

Would it be worth considering building two versions of ports, one 
dependent on other ports and one dependent on base? They could have 
different version suffixes and the build system could make packages to 
depend on one version or another. Those who build their ports could 
choose one option or the other as the default to only build one version.

Grzegorz