From owner-svn-src-projects@FreeBSD.ORG Wed Dec 10 22:54:50 2014 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E18BEA for ; Wed, 10 Dec 2014 22:54:50 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E1317D for ; Wed, 10 Dec 2014 22:54:50 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id eu11so3685400pac.25 for ; Wed, 10 Dec 2014 14:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UWBLWxNMJsD8cVe4/6SEnmZCFLc025OFQLX/puwQXVs=; b=fMczt+mbch6NpTCU57PDmQiw2IQQ8xzp3Y5aJRj+jOuWbgKdI1/D8j/JrgeoywIvrR /fUWpDzjmg3Fv70uIb6mPhZ0IG/oSTj4tTHsGwPqYMm+sK/NEhdTKQKLznAXOVpZlKUt BMJUyEzXemL49Bja4uLCr/2nsMR0zAK7X0FtM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:mime-version:subject :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=UWBLWxNMJsD8cVe4/6SEnmZCFLc025OFQLX/puwQXVs=; b=MjeWPL5pzAJSeXZQwguhB82BKLWPIIm6gU+F8wMqa0o6oG9MhFmfTVaqz1rjKYzv// hXor8nNfZmM7a4hlXvj38IY+TOzBpu+OC74+6ksCD+OahOtePjprriFPOnD92fy1QZxa vP0FfxG7KIvdNWJUyaqn9JYZCesDBl85GGOY24tAXvBGkRt7FiC/nOalhQzdk+IoRut0 l/7ybEpuk78mmDoPacZXcP3wEZor7xsEKIc7eUIQfkCB+x6/5vq8bdja3iWQ2M3dcIFu v2o4bMn+iH2MdZqOM3TMiOU7FeVUiVI+vk+QXYYqqpIMr4F9fooIPYrSM2L7c1P65OmV p1oA== X-Gm-Message-State: ALoCoQl/y94gV7qT0l01+evRxMPnjGEIbUsX/Kf3L8YowH8dx6Lx34/smf/fnjs3ZVWYSQCIhe5r X-Received: by 10.70.98.233 with SMTP id el9mr11536629pdb.132.1418252089844; Wed, 10 Dec 2014 14:54:49 -0800 (PST) Received: from lgmac-vviswanat.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id td4sm5132557pbc.36.2014.12.10.14.54.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 14:54:49 -0800 (PST) From: Warner Losh X-Google-Original-From: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: svn commit: r275601 - projects/building-blocks In-Reply-To: <5488C18D.2020502@FreeBSD.org> Date: Wed, 10 Dec 2014 14:54:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <81CD2798-E2EC-4D2F-A204-EE24CDB1B164@gmail.com> References: <201412080743.sB87h3j9044019@svn.freebsd.org> <1418054094.1064.147.camel@revolution.hippie.lan> <5485D8B5.90604@FreeBSD.org> <20141210210307.GX25139@funkthat.com> <5488C18D.2020502@FreeBSD.org> To: Mark Peek X-Mailer: Apple Mail (2.1993) Cc: src-committers@freebsd.org, Ian Lepore , John-Mark Gurney , Garrett Cooper , svn-src-projects@freebsd.org, Garrett Cooper X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 22:54:50 -0000 > On Dec 10, 2014, at 1:56 PM, Mark Peek wrote: >=20 > On 12/10/14 1:19 PM, Garrett Cooper wrote: >> On Dec 10, 2014, at 13:03, John-Mark Gurney wrote: >>=20 >>> Mark Peek wrote this message on Mon, Dec 08, 2014 at 08:58 -0800: >>>> On 12/8/14 7:54 AM, Ian Lepore wrote: >>>>> On Mon, 2014-12-08 at 07:43 +0000, Garrett Cooper wrote: >>>>>> Author: ngie >>>>>> Date: Mon Dec 8 07:43:02 2014 >>>>>> New Revision: 275601 >>>>>> URL: https://svnweb.freebsd.org/changeset/base/275601 >>>>>>=20 >>>>>> Log: >>>>>> - Document why usr.bin/vi needs to be built as part of = bootstrap-tools >>>>>> ...snip... >>>>>=20 >>>>> Is there any chance someone who understands vi could evaluate what = it's >>>>> being used for and perhaps eliminate it? I know just enough about = vi to >>>>> get out of it if I accidentally get in. >>>>>=20 >>>>> When I looked into this a few days ago it appears to be using it = to sort >>>>> the data before compiling (an optimization that problably hasn't = been >>>>> important to do since the 90s). Could another existing build tool = such >>>>> as awk do the job? >>>>=20 >>>> My reading of that code agrees with yours in that it is using 'ex' = to >>>> prioritize some terminal entries in the termcap file. However, it = is then >>>> hashed into a berkeleydb via cap_mkdb which should render the = initial >>>> prioritization useless. Rather than rewriting it I would suggest = completely >>>> removing the reordering and the ex dependency. >>>=20 >>> There was some dicussion about removing some of the various = databases, >>> and having commonly used entries at the top would help in this = case.. >>=20 >> I was looking at Fedora 20=92s termcap just the other day, and I was = surprised at the brevity in the file (only a couple entries for = =93xterm=94). They also have it split into multiple files instead of = just one file too (/usr/share/vte/termcap-0.0/xterm). Maybe this would = be a good move going forward (or not=85???)? >>=20 >> Why should the .db files be removed? I think reducing the bloat from = the files due to overestimated bucket sizes would be a good first start = instead of just removing them altogether (I noticed that termcap.db has = the same bloat problem services.db has). >=20 > Taking a step back, which problem are we trying to solve? I see: > 1. remove a vi (ex) dependency from the bootstrap-tools > 2. termcap is too big and should be minimized > 3. remove the use of .db files >=20 > Both #2 and #3 seem to need more thought, discussion and debate before = implementing them. #1 can be easily accomplished without any loss of = functionality given we are currently using .db files and don't require = the reorder step during the bootstrap. #2 and #3 can then be solved = independent of #1 while allowing for a more streamlined bootstrap phase. >=20 > Also, there is etc/termcap.small in the system should there need to be = one and the larger termcap could become a port. termcap is fine the way it is. termcap.small is there when you don=92t = want to use the .db files. With current disk sizes, the .db file bloat = is a total non-issue. If you cared about that, you=92d use = termcap.small. This calculus has been true for about a decade now and = the number of people that care about using termcap.small has been = declining=85 Nothing has really changed with this... Warner=