From owner-svn-src-projects@FreeBSD.ORG Wed Dec 10 21:56:38 2014 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C49869E7 for ; Wed, 10 Dec 2014 21:56:38 +0000 (UTC) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id 5895EA49 for ; Wed, 10 Dec 2014 21:56:37 +0000 (UTC) Received: (qmail 64827 invoked by uid 0); 10 Dec 2014 21:56:31 -0000 Received: from 70.35.46.82 (HELO ?192.168.128.65?) (70.35.46.82) by relay00.pair.com with SMTP; 10 Dec 2014 21:56:31 -0000 X-pair-Authenticated: 70.35.46.82 Message-ID: <5488C18D.2020502@FreeBSD.org> Date: Wed, 10 Dec 2014 13:56:29 -0800 From: Mark Peek User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Garrett Cooper , John-Mark Gurney Subject: Re: svn commit: r275601 - projects/building-blocks References: <201412080743.sB87h3j9044019@svn.freebsd.org> <1418054094.1064.147.camel@revolution.hippie.lan> <5485D8B5.90604@FreeBSD.org> <20141210210307.GX25139@funkthat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org, Garrett Cooper , Ian Lepore 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 21:56:39 -0000 On 12/10/14 1:19 PM, Garrett Cooper wrote: > On Dec 10, 2014, at 13:03, John-Mark Gurney wrote: > >> 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 >>>>> >>>>> Log: >>>>> - Document why usr.bin/vi needs to be built as part of bootstrap-tools >>>>> ...snip... >>>> >>>> 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. >>>> >>>> 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? >>> >>> 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. >> >> There was some dicussion about removing some of the various databases, >> and having commonly used entries at the top would help in this case.. > > I was looking at Fedora 20’s termcap just the other day, and I was surprised at the brevity in the file (only a couple entries for “xterm”). 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…???)? > > 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). 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 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. Also, there is etc/termcap.small in the system should there need to be one and the larger termcap could become a port. Mark