Date: Wed, 10 Dec 2014 14:54:47 -0800 From: Warner Losh <wlosh@netflix.com> To: Mark Peek <mp@FreeBSD.org> Cc: src-committers@freebsd.org, Ian Lepore <ian@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, Garrett Cooper <yaneurabeya@gmail.com>, svn-src-projects@freebsd.org, Garrett Cooper <ngie@freebsd.org> Subject: Re: svn commit: r275601 - projects/building-blocks Message-ID: <81CD2798-E2EC-4D2F-A204-EE24CDB1B164@gmail.com> In-Reply-To: <5488C18D.2020502@FreeBSD.org> References: <201412080743.sB87h3j9044019@svn.freebsd.org> <1418054094.1064.147.camel@revolution.hippie.lan> <5485D8B5.90604@FreeBSD.org> <20141210210307.GX25139@funkthat.com> <FDAF179A-B085-4EE2-AE58-445A2B64071C@gmail.com> <5488C18D.2020502@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Dec 10, 2014, at 1:56 PM, Mark Peek <mp@FreeBSD.org> wrote: > > On 12/10/14 1:19 PM, Garrett Cooper wrote: >> On Dec 10, 2014, at 13:03, John-Mark Gurney <jmg@funkthat.com> 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. termcap is fine the way it is. termcap.small is there when you don’t 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’d 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… Nothing has really changed with this... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?81CD2798-E2EC-4D2F-A204-EE24CDB1B164>