Dependencies: base vs. ports (Was: Re: ports/187468)

[Bryan Drewery]

> On Mar 11, 2014, at 23:48, Alexey Dokuchaev <danfe at FreeBSD.org> wrote:
> 
>> On Tue, Mar 11, 2014 at 07:50:37PM -0500, Bryan Drewery wrote:
>> This goes against our plans to have all ports depend only on ports. I
>> admit this has not been communicated well. libexecinfo should probably
>> be moved to /usr/lib/private on head to prevent ports from using it.
> 
> [ Taking this to ports@ as it deems important on its own ]
> 
> What's wrong with depending on system libraries?  OSVERSION check does
> indeed make it a bit hackish; I would use !exists(/usr/include/execinfo.h)
> instead, but the change itself is fine, I also do so (cf. biology/ugene).

You conveniently trimmed out a lot of context here. This thread was not
'Re: ports/187468' on this list.

> 
> Any port depends on our libc.  Shall we package it as well?  Many ports
> depend on zlib, bzip2 (all in the base), etc.  Does this plan of yours say
> that soon we would have to add archivers/bzip2 in LIB_DEPENDS for any port
> that wants to link against libbz2?
> 
> Was it discussed somewhere, in public?  Because it is certainly news for
> me; moreover, I *like* to depend on base for simple things, just as I like
> to use system compiler whenever possible.
> 
> ./danfe

Obviously we will use libc from base right now. As for compiler, we were
in very public plans last year to use a ports compiler but that fell
through.

This project will take a long time.

Having ports mostly depend on port libraries only became more easily
possible and part of the plans with recent PRIVLATELIB support in base.

PRIVLATELIB is a way to mark a library in base as private, it installs
into /usr/lib/private. This prevents any port or user-application from
using it. Removing the support burden from the project and allowing us
to better understand the scope of issues (EN/SA) that come up from that
library.

Problems with depending on base:

1. Creates a security advisory burden. Take openssl for example, any
issue there requires an SA (security advisory), freebsd-update, and if
there are ABI changes then requires rebuilding of ports and base tools.
The ports have no way to automatically rebuild. This is a manual item in
a document to do so.
2. Head packages are impossible. Every week lately there has been some
userland change that required clearing and rebuilding head packages.
Take the recent libelf.so.1 bump to libelf.so.2. Had that library been
private and only ports depending on the port version, the port build
tools would have detected the version bump and rebuilt the ports.
However because it was not in ports, ports had to manually be rebuilt by
reading /usr/src/UPDATING.
3. By depending on base we can only support the oldest release, or
depend on the port version anyway on the oldest releases.
4. Ports is a very fast moving target and src is a very slow moving
target. We have to support 5+ year old systems. This gets complex that
as a maintainer your port may be using 3 or 4 different versions of a
library. If it depended on the port version then it would be much
simpler. We have *5* official releases right now and head that all
require packages right now.

Take for example libc++. The C++ standard is changing every 4-5 years
now. If at FreeBSD 13,14 we are still supporting 10 with its C++11-only
features, we'll need the ports to use the port version of libc++ on
those systems to get (final) C++-14 or C++-17. Might as well use the
port version on all.

Currently converted libraries in head:

libssh
libucl
libunbound
libheimipcs


Recently we are working to move libreadline to private as well and fix
up all the ports. We also plan to do libdialog and libncurses soon. If
we could actually use a recent or custom libdialog, the dialog4ports
could expand a lot. Instead we are stuck supporting only the oldest
release, or bundling libraries which is very wasteful on space.

Base has way too much in it. Many libraries are imported only for some
tool that is imported. The maintainer never intended for that library to
suddenly be a promised library from the project. But many have become that.

Most of all consider a goal of packaging base. The final implementation
here is not decided. However, we definitely don't want 2 versions of
openssl and all the other libraries. We only want 1 true version for all
base and ports packages. The SA need for base goes away once all base
tools also use the port library versions as well, for sensitive
libraries such as openssl. This merges into the pkg audit/vuxml scheme
and greatly reduces workload for secteam.

Lastly ports should be fully self-contained as much as possible.
Supporting 6 different releases/versions right now is very difficult
(8.3,8.4,9.1,9.2,10.0,head). I am even working on bootstrapping bmake
into the build to allow us to remove all of the compatibility code and
simplify dev/test. The recent QT5 import did not work on 8.3 as it was
using newer make :tl which 8.3's fmake did not have. This broke 8.3
packages. An exp-run would not have caught it and other similar cases as
we don't have the time to test on 6 different branches. Further benefits
for bootstrapping bmake is once 8.3 is EOL we will be removing older
compatibility such as :L.

Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20140312/d63c8194/attachment.sig>