1 |
* Stuart Herbert <stuart@g.o> [2004-04-29 14:30]: |
2 |
> On Thursday 29 April 2004 22:04, Ajai Khattri wrote: |
3 |
> |
4 |
> Here's the points I want to tackle include: |
5 |
> |
6 |
> * standard way for ebuilds to interact with database servers locally |
7 |
> * support for ebuilds to work with a remote database server |
8 |
> * standard way for ebuilds to install new databases |
9 |
> - naming schemes for databases |
10 |
> - naming schemes for users that apps use |
11 |
> * a standard way to automate upgrading databases when we upgrade apps |
12 |
> - auto-generation of SQL upgrade scripts |
13 |
> (we can't rely on UPSTREAM to provide them) |
14 |
> * a standard way to automate removing databases when we remove apps |
15 |
> - what do we remove |
16 |
> - when do we remove it |
17 |
> * hooks so that we can add new databases to backup schemes automatically |
18 |
> - oh the fun ;-) |
19 |
> |
20 |
> I think we need to put a design down as a GLEP, as introducing the tool or |
21 |
> tools to do all of this will impact users and devs alike. |
22 |
> |
23 |
> Thoughts, comments? Anyone interested in helping out on this? |
24 |
> |
25 |
> Best regards, |
26 |
> Stu |
27 |
|
28 |
I think this is a really good idea. The ebuild config mechanism is |
29 |
not all that smart. Since, there is work on an installer there should |
30 |
be some mechanism for the installer to query an "install specification |
31 |
file" per package. Something like an installshield script, but it |
32 |
needs to export configuration items (ie: parameters, possible values, |
33 |
etc). The interface should be generic enough so that any type of |
34 |
configuration utility (GUI, console, or non-interactive) can run the |
35 |
configuration. |
36 |
|
37 |
Depending on the time frame... I may be able to help out on this. |
38 |
Graduation from college is at the end of this year (I hope :). |
39 |
|
40 |
-Ryan |