1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
Objective
There is a lot of 3rd party software providers that resemble overlays
or repositories of Linux distributions in some way. For example: pypi,
CRAN, CPAN, CTAN, octave-forge, ELPA. It's 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.
There is a number of solutions for this problem in Gentoo. But here
another problem lies: there are special dedicated “g-helpers” 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 necessary for
ebuild and overlay generation, with uniform UI and with good
integration with system package manager.
Deliverables
At the end of the project there should be a framework and number of
backends for some of the 3rd party software providers. This framework
should make writing of those g-helpers easier and regular.
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
should not be changed by backends. Integration with system may need
patching of some existing tools (like layman).
Framework should have: - basic logic for ebuild and overlay
manipulation, dependencies resolving, patching and so on - cli, that
allows users to generate separate ebuilds and even overlays with
available backends - integration with other system tools (I mean
layman, as I'm not really familiar with tools used by other package
manglers. But supporting them would be a good idea as well).
Backend should have everything specific for a given 3rd party software
provider: concrete algorithms for ebuild-generation, eclasses,
databases with information about available software and so on.
To test current code run `python3 scripts/run_tests.py' or
`python2 scripts/run_tests.py'
Note that for tests of an ELPA backend you'll need dev-python/sexpdata
available in `jauhien' overlay (just do `layman -a jauhien')
An ebuild for g-sorcery was added to `jauhien' overlay. At the moment
package is unusable, but it should change in a nearest future.
|
GitWeb
