From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by krisdoz.my.domain (8.14.5/8.14.5) with ESMTP id s7K3F6k1025192 for ; Tue, 19 Aug 2014 23:15:07 -0400 (EDT) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by scc-mailout-02.scc.kit.edu with esmtp (Exim 4.72 #1) id 1XJwMb-0000ck-4Y; Wed, 20 Aug 2014 05:15:05 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1XJwMb-00063L-11 for discuss@mdocml.bsd.lv; Wed, 20 Aug 2014 05:15:05 +0200 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1XJwMa-0001mp-RN for discuss@mdocml.bsd.lv; Wed, 20 Aug 2014 05:15:04 +0200 Received: from schwarze by usta.de with local (Exim 4.77) (envelope-from ) id 1XJwLq-00078I-HB for discuss@mdocml.bsd.lv; Wed, 20 Aug 2014 05:14:18 +0200 Date: Wed, 20 Aug 2014 05:14:18 +0200 From: Ingo Schwarze To: discuss@mdocml.bsd.lv Subject: mandoc-1.12.4 released Message-ID: <20140820031418.GN17622@iris.usta.de> X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Hello, you were no doubt already expecting the mandoc = mdocml 1.12.4 release announcement - here it is, i have just uploaded the release tarball to : http://mdocml.bsd.lv/snapshots/mdocml-1.12.4.tar.gz This is purely a backward compatibility release for systems requiring apropos(1) and makewhatis(8) but lacking either SQLite3 or fts(3). Anybody who has both SQLite3 and fts(3) as well as anybody who does not need apropos(1) and makewhatis(8) should use 1.13.1 instead, released ten days ago. The 1.12.4 release contains all feature improvmenents and bugfixes that are also contained in 1.13.1, with the exception of the main 1.13.1 feature, the SQLite3 based semantic search suite. Instead, the 1.12.4 release still contains the old Berkeley DB based search suite. While the non-database-related code in 1.12.4 is almost the same as in 1.13.1, note that choosing the database backend is not just a matter of which one is more convenient for you. If there is any way how you can use the SQLite3 version, you really should. While the version based on Berkeley DB is usable, many important improvements have been achieved in the SQLite version regarding functionality, reliability, and performance. See my BSDCan talk, pages 16-24 for details about what is *not* available in 1.12.4, but only in 1.13.1: http://www.openbsd.org/papers/bsdcan14-mandoc.pdf The 1.12.4 release does contain a small number of post-1.13.1 bugfixes in non-database code, but that shouldn't be a reason to stay on the 1.12 branch. These bugfixes will of course make it into 1.13.2 when that comes out. For details, see the release notes: Many thanks to Thomas Klausner (NetBSD), Paul Onyschuk (Alpine Linux), and Kristaps Dzonsons (bsd.lv) for release testing! In particular, Kristaps spent quite some time and effort hunting memory access issues with valgrind, which led to a couple of bugs being fixed in the last few days. What about the future? At this point in time, i will stop merging anything to the 1.12 branch, neither bugfixes nor feature improvements, because frankly, i don't see why a 1.12.5 release might ever be needed. So you should all get ready to upgrade to 1.13.2 when it comes out, probably later this year. It will contain a compat implementation of fts(3), so you need not worry much about that, but it will of course require SQLite3 if you want to use the search suite. However, if it turns out the for any downstream distribution, upgrading to the 1.13 branch must be delayed and a 1.12.5 is needed, it will be possible to do a merge then - though obviously, i don't promise that i will do it, i'm just saying that it can be done if needed. Please speak up as soon as you see a need. The feature i'm currently working on is integrating a reimplementation of the traditional man(1) utility into mandoc(1); thanks to Paul Onyschuk for suggesting that feature! From a user perspective, it will work just like it always did. But internally, it will be completely different. Instead of searching through directories for the requested page(s), it will use the mandoc.db(5) database to find the matching page(s), then directly invoke the mandoc(1) formatting code on the file name found in the database, without any fork(2) or exec(2) in between. The main benefit is that this will make hard- and symlinks among manual pages and X.org style .so-only pages obsolete. As long as you put the right .Nm macros into the NAME section of your manual, put it into the right directory, and keep the mandoc.db(5) database up-to-date with makewhatis(8), it will be found. In a typical operating system installation, this will free 3000-4000 inodes. There is more potential to this approach. For example, it allows to directly go from an apropos(1) invocation to actually displaying a manual, without going back to the shell and typing another command in between. That idea has been devised by Kristaps years ago but lain dormant since, admittedly mostly due to my initial scepticism, but in the context of the present approach as a whole, i now clearly see the point. Stay tuned! Ingo -- Ingo Schwarze http://www.openbsd.org/ http://mdocml.bsd.lv/ schwarze@openbsd.org schwarze@mdocml.bsd.lv -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv