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: >=20 > On 12/10/14 1:19 PM, Garrett Cooper wrote: >> On Dec 10, 2014, at 13:03, John-Mark Gurney <jmg@funkthat.com> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?81CD2798-E2EC-4D2F-A204-EE24CDB1B164>