Subject: Re: Google Summer of Code project ideas
To: Jan Schaumann <jschauma@netmeister.org>
From: Chapman Flack <nblists@anastigmatix.net>
List: tech-pkg
Date: 04/21/2006 15:52:59
Jan Schaumann wrote:
> *  pkg_install rewrite --  pkg_install, the set of binary utilities used
>    to install, remove, create and (to some extent) update packages, has
>    to be rewritten from scratch because the current code is very
>    difficult to extend and modify. Aside from rewriting these tool set,
>    it would be interesting to add new functionality (basically improve
>    updates).
> 
>    You can find more information about how the new tool would need to be
>    in http://mail-index.netbsd.org/tech-pkg/2006/04/15/0012.html

This would be an excellent opportunity to resolve pkg/32128, which
should be easy, as the necessary code appears to be there and nearly
complete, only not working right for some possibly trival reason.

From the referenced e-mail of 4/15:

> But I'd add one (very important, in my opinion) feature to the mix:
> the ability to easily upgrade whole installations either from source,
> from binaries or both.

To make this work best when not everything needed is available in
binary form, or when the binary packages are not the same version
as the sources provide, there should be intelligent interaction
between pkg_install and the pkg Makefiles, as described (under "a
slicker way, possible future work") in
http://mail-index.netbsd.org/tech-pkg/2005/03/20/0023.html

> - Programming language?

> We also have sh(1) as has been suggested some times.  I'm afraid of the
> results of such choice.  sh programs tend to grow uncontrollably ...
> sh is a language but it cannot do anything without cut, grep, etc. And we
> already now how difficult is to stick to the minimum common option set.

Another region of design space that wasn't mentioned is where you
implement several choice bits--Dewey wildcards, pkgdb interaction, ftp
connections, say--in a compiled language as a loadable library for an
extensible scripting language like Tcl or ksh. It would add a dependency
on the language interpreter, but as both are now open-source licensed
and both make obsolete the "cannot do anything without cut, grep, etc."
issue, maybe that could be thinkable. I do agree that the attempt to do
anything like pkg_install in a nonextensible sh(1)-era shell would be
sheer masochism (sadism, too, for other maintainers).

-Chap