From owner-freebsd-current@freebsd.org Mon Apr 18 20:31:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65A7FB13CE3 for ; Mon, 18 Apr 2016 20:31:06 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id B1B531AD0; Mon, 18 Apr 2016 20:31:05 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Mon, 18 Apr 2016 22:30:58 +0200 Authentication-Results: connect.ultra-secure.de; iprev=pass; auth=pass (plain); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 217.71.83.52 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=217.71.83.52; helo=[192.168.1.200]; envelope-from= Received: from [192.168.1.200] (217-071-083-052.ip-tech.ch [217.71.83.52]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id CC110488-26DE-434F-B3E6-566A00118C5B.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES256-SHA verify=NO); Mon, 18 Apr 2016 22:30:51 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Rainer Duffner In-Reply-To: <57153E80.4080800@FreeBSD.org> Date: Mon, 18 Apr 2016 22:30:48 +0200 Cc: freebsd-current Current Content-Transfer-Encoding: quoted-printable Message-Id: <2D6C2427-806C-4F18-8B1C-263CCC34CF21@ultra-secure.de> References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.3124) X-Haraka-GeoIP: EU, CH, 451km X-Haraka-ASN: 24951 X-Haraka-GeoIP-Received: X-Haraka-ASN: 24951 217.71.80.0/20 X-Haraka-ASN-CYMRU: asn=24951 net=217.71.80.0/20 country=CH assignor=ripencc date=2003-08-07 X-Haraka-FCrDNS: 217-071-083-052.ip-tech.ch X-Haraka-p0f: os="Mac OS X " link_type="DSL" distance=13 total_conn=1 shared_ip=N X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 103, bad: 0, connections: 262, history: 103, asn_score: 36, asn_connections: 44, asn_good: 36, asn_bad: 0, pass:all_good, asn, asn_all_good, relaying X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 20:31:06 -0000 > Am 18.04.2016 um 22:07 schrieb Lev Serebryakov : >=20 > On 18.04.2016 22:40, Glen Barber wrote: >=20 >> This granularity allows easy removal of things that may not be wanted >> (such as *-debug*, *-profile*, etc.) on systems with little storage. = On >> one of my testing systems, I removed the tests packages and all debug >> and profiling, and the number of base system packages is 383. > IMHO, granularity like "all base debug", "all base profile" is enough > for this. Really, I hardly could imagine why I will need only 1 debug = or > profile package, say, for csh. On resource-constrained systems NanoBSD > is much better anyway (for example, my typical NanoBSD installation is > 37MB base system, 12MB /boot and 10 packages), and on developer system > where you need profiled libraries it is Ok to install all of them and > don't think about 100 packages for them. >=20 > Idea of "Roles" from old FreeBSD installers looks much better. Again, > here are some "contrib" software which have one-to-one replacements in > ports, like sendmail, ssh/sshd, ntpd, but split all other > FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static = libraries. > Yes, lib32 on 64 bit system. >=20 > It seems that it is ideological ("holy war") discussion more than > technical one... =46rom the discussion, I believe it=E2=80=99s primarily driven by the = need/desire to have small packages to make updates easier on the = mirror-servers. I=E2=80=99m really not sure (yet), which is worse: the current system = that pulls down some 14k small files for a system-upgrade - or a system = where the base-system is split into almost 800 packages. freebsd-update is =E2=80=9Eonly" unreliable if - you go through a proxy with authentication - that proxy doesn=E2=80=99t do http-pipelining (or does it bad/is = broken is this respect) (certain version of Sophos UTM for example=E2=80=A6= ) AFAIK. As for the packages: I wouldn=E2=80=99t mind =E2=80=9Efatter=E2=80=9C = packages. I=E2=80=99d mirror them locally anyway (I hope this is = possible - AFAIK, the freebsd-update files are not supposed to be = mirrored), and I don=E2=80=99t have a thousand servers to pull them down = all at once anyway (working on that ;-)). I=E2=80=99m pretty sure the impact on the current FreeBSD delivery = infrastructure would be quite substantial, if updates came in 60MB = chunks - esp. if there was some sort of auto-update mechanism in place. Fast-forward to the future where a lot (millions?) more embedded devices = are based on FreeBSD and pull updates from the FreeBSD infrastructure. Or if the container hype-train reached FreeBSD and people started to = containerize everything, resulting in even more base-package update = downloads. So, I can see both sides. Neither I=E2=80=99m really satisfied with. I hope a way is found to manage these number of packages without losing = sanity and that a normal pkg info doesn=E2=80=99t list them. And that pkg upgrade doesn=E2=80=99t upgrade base-packages.