I plan to implement either a tool or small set of tools to aid in working with Gentoo portage overlays ( http://overlays.gentoo.org/ ). In particular, I want to address troubles with maintaining an overlay that contains ebuilds that have been copied from portage. These are normally copied into my overlay where I can play with trying to fix a bug I've observed in the official ebuild. My overlay is my place to deposit fixes and make them available to others until I can 1. get a patch into the bugzilla and 2. that bug is accepted and patch applied by a Gentoo dev.

My overlay is managed by mercurial:
hg clone http://ohnopub.net/hg/ohnobinki_overlay

The following are the most important features of my tool/tools:
1. Be able to cleanly and automatically copy an official Gentoo ebuild into my overlay so that I don't have to use ``cp'', ``hg add'', and ``hg commit'' manually.

2. Be able to semi-automatically update ebuilds in my overlay based on changes in portage. For example, certain ebuilds sit in my own overlay for quite a long period of time as the Gentoo maintainers don't have to fix every bug or make every enhancement I file bugs for (i.e., https://bugs.gentoo.org/272963 ). Thus I want to have an ebuild with that feature in my overlay. But Gentoo maintainers will bump ebuilds (rename them when a new version of software is released) and make fixes for different bugs (i.e., either trivial bugs that won't impact users too much or high-priority bugs such as security problems). I currently have no way to search for changes in the official portage tree, extract them, and check if they can be semi-automatically applied to my own overlay. This process should be interactive to avoid automation from causing something to be messed up.

3. Providing a way to compare my ebuilds to official portage's. I sometimes forget why I even imported a package into my overlay and it'd be nice to wrap around ``diff -u'' so that I can more quickly and efficiently check the differences between my package and the official versions.

Timeline for each of the above features:
1. This should be completable/functional in a week or two. I.e., by April 10 or so

2. This will be more complicated. The partial functionality, of determining which CVS revision my ebuild is at will come first. Then the ability to analyze the official portage tree for changes more recent than my ebuild should be available by April 20. The semiautomatic/interactive overlay updating process will hopefully be finished by April 30.

3. This should be easier then #2, thus it should be worked on around the same time as #1 as this goal deals with similar information as #1 does.


Types of programming:
I expect much of this to involve ``shell-outs'' -- calls to the system-installed diff utility, to CVS (as long as official portage is still CVS, they're thinking about switching to git), calls to Mercurial's CLI.

I am wondering if, since mercurial is written in python, it would make sense to try to call its API at a python-level. This is still to be determined but is possible and would make the experience of writing python code complete (i.e., working with a third-party python package).

All of these utilities will be CLI. All would be non-interactive except possibly the semi-automatic process for #2. This user-interactivity is the only place where I'd see myself using streams for more than just printing status messages to the console.

I definitely will need to use looping constructs and arrays. There will be potentially use for associative arrays describing how to call the CVS commands so that one could just write up another array with the equivelent git commands (though I've heard that CVS is so assimilar to git that this'll be hard to figure out at first).