[gentoo-soc] GSoC 2013: Framework for automated ebuild generators

[Jauhien Piatlicki]

Hi all,

I would like to contribute some code during GSoC-2013. I'm interested in
the idea of Rafael Martins ``Framework for automated ebuild generators''.

As all of us know there are lot of 3rd party software providers that in
some way resemble overlays or repositories of Linux distributions.
Examples are pypi, CRAN, CPAN, CTAN, octave-forge, MELPA. Lots of them.
It is quite clear that all this software available through different
mechanisms (such as package.el for Emacs or pkg command in Octave) will
never have separately maintained ebuilds in Gentoo tree or even in
overlays. Installing such a software with its own distribution system
does not seem like a good idea, especially if one needs to install it
system-wide.

And really there is a solution in Gentoo for this problem: even a number
of solutions. And here another problem lies: we have a special dedicated
g-helpers (let call them in this way) for a number of 3rd party software
providers. But, as Rafael Martins states ``each one tries to solve the
very same problems on its own unique and "innovative" way''. While it
would be really nice to have a solid base framework with realization of
all the basic algorithms needed for ebuild and overlay generation, with
uniform UI and with good integration with system package manager.

Finally we should have such a framework and number of backends for every
type of 3rd party software provider. This framework should make writing
of those g-helpers more easy and regular without need for reinventing
wheels every time.

Framework should have:
- basic quite common logic for ebuild and overlay manipulation,
dependencies resolving, patching and so on
- cli, that allows users generate separate ebuilds and even overlays
with available backends
- integration with other system tools (here I mean layman in the first
place, as I'm not really familiar with tools used by other package
manglers, but supporting them would be nice as well).

Backend should have anything specific for a given 3rd party software
provider such as concrete algorithms for ebuild-generation, eclasses,
databases with information about available software and so on.

At the end of this project these items should be created:
- framework
- number of backends (3 or 4)
- documentation both for users and developers of new backends

One of the main problems here is creation of framework general enough to
handle and to be usefull for very different software providers. So the
first point in this project is studying of different kinds of them (This
part of project was successfully begun)) ).
Then common design of framework and typical backend should be developed
(as a source of an inspiration I will use existing solutions like
g-octave and R_overlay at least to see good and bad ideas they use).

At the moment I see this framework as a number of classes in python that
can be inherited and expanded in backends with the specific logic. All
the logic related to the interaction with user, portage and overlay
tools should be implemented in the framework and normally not changed by
backends. Integration with system may need patching of some existing
tools (like layman), but it isn't a problem as far as I understand.

Before the mid-term a working framework and at least one backend should
be developed.
After the mid-term I'm planning to improve framework and ideas behind it
and also to develop a number of additional backends and documentation.

And the last thing. A little about myself. I'm a student at Jagiellonian
University in Cracow (Poland). I'm studying Theoretical Physics at
Master courses. Before it I've graduated from Belarusian State
University (Minsk, Belarus) with degree in Radiophysics/Computer
Security. I have a working experience as a Software Developer (C/C++ on
Linux).
I really like way thing are done in Gentoo. I use this system for years.
I have some contributions to it (mainly Physics-related packages). And
also I've tried to write some ebuild-generation stuff
(https://github.com/jauhien/g-common) but as I've seen there is this
GSoC idea, that will bring us much more general tool I've thought it
should be completely rewritten. )

It seems that's all so far.

Looking for any suggestions and comments.
If no complains I will proceed with submitting of my proposal to Google.

Jauhien