Re: GSoC Project: Replacement for Apropos

[Julio Merino <jmmv%NetBSD.org@localhost>]

On Sun, Mar 20, 2011 at 7:10 PM, Abhinav Upadhyay
<er.abhinav.upadhyay%gmail.com@localhost> wrote:
> Hi,
> My name is Abhinav Upadhyay, and I am a 4th year student of Bachelor
> of Technology from India.

Hello Abhinav,

Welcome to NetBSD!

[...]
> I had a couple of questions though:
> 1.) Which language would you prefer to use ? I think Python would be a
> good choice.

You should be aware that the NetBSD *base* system does not include
Python, Perl nor Ruby and there are no plans to import them.  The
major languages currently supported as part of the base system are: C,
C++, shell and (since very recently) Lua.

If you were to use Python, your project would be restricted to live in
the packaging system (pkgsrc).  This would be OK, but I'd imagine that
the project proposal looks for a replacement to apropos that can be
bundled with the NetBSD base system.  This means that you can't use
(there may be an exception; see below) any tools nor libraries that
are not already part of the base system.

I think that, when we were discussing this project proposal, the most
prominent idea was the one you mention: using SQLite.  Be aware that
SQLite is also not part of the base system, but convincing the
developers to import it would be much easier than convincing them to
import Python ;-)

> 2.) And if the user installs some new system utilities or tools, and
> new mandocs are added for them, then how would we add those documents
> to the index ? I think the indexer process could be called
> automatically after installing the new mandocs, which would run in the
> background and index the new documents.

That's an easy enough thing to do from the packaging system (pkgsrc)
and I would not worry too much about it for now.  We currently do this
for many different packages that install extensions for more basic
libraries/services.  For example, any package installing GIO modules
must trigger a rebuild of glib's gio cache both at install and
deinstall time.

You can imagine something like this: when package A gets installed, we
execute "add-manpages-to-index <manpage1> <manpage2> ..." and when the
package A is deinstalled, we call "remove-manpages-from-index
<manpage1> ...".  (The long command names are here for illustrative
purposes only.)  You'd then have a nightly cron job that rebuilds the
whole index from scratch to ensure it is truly consistent.

The only thing of concern here is whether you allow to update the
index incrementally or from scratch.  In the example I gave above, you
would get a list of the new manpages on the command line so you would
have a chance of doing a incremental index.  This seems like a more
efficient approach, specially when you are installing hundreds of
packages at once (think "pkg_install gnome"), so the indexing system
should allow it.

> I am really eager to work on this. I also wanted to know if you
> require students to perform some kind or task to judge their
> capabilities and filter the applications ?

I'm not sure right now if we perform any such filtering.

You can start by reading
http://www.netbsd.org/contrib/soc-application.html and following the
tips in there.

And, if you have never used NetBSD before, start doing so as soon as
you can :-)  Install it in a virtual machine (or, preferably, a real
machine), configure your own kernel, rebuild the whole system from
scratch, install packages from pkgsrc, familiarize yourself with the
structure of the source tree, etc.

Ah, lastly, let me note that the comments above are my personal
opinions only.  In your project proposal, you may want to describe
multiple alternatives of implementing this new tool, weight their pros
and cons and choose the one that you think is best.

If you have any further questions, keep them coming!

-- 
Julio Merino / @jmmv