svn commit: r275601 - projects/building-blocks

[Warner Losh]

> On Dec 10, 2014, at 1:56 PM, Mark Peek <mp at FreeBSD.org> wrote:
> 
> On 12/10/14 1:19 PM, Garrett Cooper wrote:
>> On Dec 10, 2014, at 13:03, John-Mark Gurney <jmg at 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