svn commit: r275601 - projects/building-blocks

[Garrett Cooper]

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).

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-projects/attachments/20141210/1c16c0f3/attachment.sig>