On 08/07/2016 23:59, Kevin Oberman wrote:
On Fri, Jul 8, 2016 at 12:20 PM, Grzegorz Junka <[email protected]> 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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
