Layman-2.0 development testing

As reported in some earlier blog posts, I've recently taken over maintaining and developing layman. I have been working on replacing the high level api with one better suited for consumer apps use. I've also changed the cli to use the new api and that has resulted in about a 20-35% speed increase for the testing I've done.

I've also been extending the mid level api a little so that it is more flexible for use as a lib in other applications. It does not require an overlay definition be input via xml file only. It can now accept a python dictionary to define an overlay or for that matter any VCS be it a development checkout, etc.., also it's location can be anywhere in the filesytem. That is something portage/pkgcore or a layman gui might use, it is not intended for the cli interface.

Some notable changes:

* New high level API
* New cli connection to the new API
* New add, sync, postsync config options for each repo type
* repo xml definitions can now be placed in the /etc/layman/overlays/ dir and they will automatically be added to the available list without adding them to the config manually
* New multiple config functions/classes allows for more flexible API use when using layman as a lib.
* It now timestamps the remote list and only downloads a new list if there is a change since it was last downloaded.
* New repo type g-common. The dep is not yet included in the ebuild as it is supplied via app-portage/g-cran from the science overlay. But if you use g-cran packages you probably already know this.
* New Message class fully capable of re-directing output to the defined output passed in. Again mostly for guis or consumer apps use.
* other code cleanups, small improvements.

So those that would like to help test:

Code:

echo 'app-portage/layman **' >> /etc/portage/package.keywords # emerge =layman-9999

Please report any issues you have with it so I can get them fixed
I would like to try and stabilize the code for a release sometime in the near future.

gentoo forum thread

Porthole 2011 GSOC project starting

Porthole has been chosen as one of this years GSOC projects. The project will encompass a complete re-structuring of porthole's backend so that it can make use of a new (soon to be stable) portage public API. Stable at this point means mostly a non changing interface for directly operating portage, getting information directly from portage while the backend code can change without fear of constant breakage for consumer apps like porthole.

The student doing the work is Cazou, the same person that worked to port kuroo to QT4 last year. This restructure is needed so that porthole can work even better with portage. It is also needed to be able to work properly with pkgcore which a backend for it will also be produced. That will give you more options as far as package managers are concerned.

More on this later...