Re: GSoC Project: Replacement for Apropos

[Abhinav Upadhyay <er.abhinav.upadhyay%gmail.com@localhost>]

Hi,

Thanks for your detailed reply. So I have installed NetBSD on QEMU as
well as on my hard disk. Next thing I am going to try to do is to
track the current version of NetBSD from CVS and build the kernel.

 I want to get started trying to do experiments with some of the
implementation ideas. So I wanted to know, where can I get the man
docs so that I can analyze their structure etc.

Also as you mentioned that this project will be part of the base
system, so are there any recommended tools that I should set up for
building the development environment ? Although I have experience of
working with the tools used in the GNU/Linux environment.

Thanks.
Abhinav


On Mon, Mar 21, 2011 at 3:43 AM, Julio Merino <jmmv%netbsd.org@localhost> wrote:
>
> 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