Date: Wed, 12 Mar 2014 07:01:20 -0500 From: Bryan Drewery <bdrewery@FreeBSD.org> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: "ports@FreeBSD.org" <ports@FreeBSD.org> Subject: Re: Dependencies: base vs. ports (Was: Re: ports/187468) Message-ID: <53204C90.4050103@FreeBSD.org> In-Reply-To: <20140312044851.GA28621@FreeBSD.org> References: <531FAF5D.1010207@FreeBSD.org> <20140312044851.GA28621@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8iN41AfkdDAuuDE2Tlukm6806Jk7DwjQ9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > On Mar 11, 2014, at 23:48, Alexey Dokuchaev <danfe@FreeBSD.org> wrote: >=20 >> 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. >=20 > [ Taking this to ports@ as it deems important on its own ] >=20 > What's wrong with depending on system libraries? OSVERSION check does > indeed make it a bit hackish; I would use !exists(/usr/include/execinfo= =2Eh) > 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. >=20 > 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 p= ort > that wants to link against libbz2? >=20 > Was it discussed somewhere, in public? Because it is certainly news fo= r > me; moreover, I *like* to depend on base for simple things, just as I l= ike > to use system compiler whenever possible. >=20 > ./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 tha= t. 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 --8iN41AfkdDAuuDE2Tlukm6806Jk7DwjQ9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTIEyQAAoJEDXXcbtuRpfPlQQH/03CYDUW5W2IAJLdEnauckMo KbfWK/Wr9f25Zm4yE5AeIve8zKvPiLH2zXKPyD8h4zCz4R5Sll9r3VP4lXZrHQzH +Ta+xOyhF5SxEn00UedjSN6B44Owi5yPcX3GhZ8X+koSGsS6bkjvhfGRiUt8PHro o+8IwMCrTSyKqGf/E1eQnQu0FhuBmbO5Au5hG0ZDNAauLxAzZE8aH3XtsRf+jPdu 3T+iDibC4BKia3BPWhHzT2Hsf5QOFnLPaD863yTfLcbPydqfI0cS6jX8IupGF2OH KOPp/ZFU8LjT4HXdMazut9bcBPglTDztewMum6eXQ12gdpFig0BrmHNDLJd7owM= =OGNT -----END PGP SIGNATURE----- --8iN41AfkdDAuuDE2Tlukm6806Jk7DwjQ9--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53204C90.4050103>