1 |
Hi guys, |
2 |
|
3 |
g-Octave 0.2 was released, as early announced here by me, then is time to |
4 |
start the work on the next version (0.3), although the tinderbox tests for the |
5 |
new package database are still pending. The patches for individual packages can |
6 |
be done in parallel with the g-Octave main development. |
7 |
|
8 |
The next version will come with 3 main new features: |
9 |
|
10 |
|
11 |
Support to optional logging |
12 |
--------------------------- |
13 |
|
14 |
I'm planning to use the 'logging' module, from the Python standard library in |
15 |
order to implement this. The implementation will allow the user to enable or |
16 |
disable the logging feature from the configuration file. |
17 |
|
18 |
|
19 |
Support to package updates |
20 |
-------------------------- |
21 |
|
22 |
g-Octave can't do package updates by now. All that the user can do is |
23 |
reinstall the package manually when he knows that the package is updated by |
24 |
the upstream. |
25 |
|
26 |
The idea is to implement an g-octave CLI option that query the package manager |
27 |
about upgrades in the installed packages and do the update for the user. |
28 |
|
29 |
|
30 |
Support to Paludis/Pkgcore |
31 |
-------------------------- |
32 |
|
33 |
g-Octave currently can only use emerge/portage to do the installation of |
34 |
packages. Although g-Octave should keep using the portage API internally, the |
35 |
users will be able choose one of the package manager frontends as they want. |
36 |
|
37 |
When I say "portage API" I mean the support to colors on the CLI and the |
38 |
stuff to do version comparations and create manifest files, basically. All |
39 |
the great stuff, like overlay management, package masking and the package |
40 |
installation itself will be done by the user's package manager of choice. |
41 |
|
42 |
|
43 |
Some ideas and thoughts about that? |
44 |
|
45 |
Thanks! |
46 |
|
47 |
-- |
48 |
Rafael Goncalves Martins |
49 |
http://rafaelmartins.eng.br/ |