| 1 |
On Sun, 2005-03-06 at 14:27 +0900, Chris White wrote: |
| 2 |
> Ok, since it was asked of by jstubbs, time to get some stuff rolling as |
| 3 |
> to API requirements. |
| 4 |
Very good idea. |
| 5 |
I'm looking at it especially from a "tinderbox" (automated building) |
| 6 |
point of view |
| 7 |
|
| 8 |
- generic get/set access to all config options |
| 9 |
We need to be able to generate a pre-defined environment for building |
| 10 |
|
| 11 |
- interface to the depgraph |
| 12 |
For certain operations, including build parallelization, we need a local |
| 13 |
copy of all dependency information. Also, repoman might be able to be a |
| 14 |
wrapper for this interface? |
| 15 |
|
| 16 |
- access to ebuild.sh functions, e.g. tell portage "unpack and patch |
| 17 |
foobar-1.2 for me" |
| 18 |
|
| 19 |
> 1) repository can be more than just a standard abiding set of files. |
| 20 |
> Maybe a custom repository, or a relational database. |
| 21 |
That's backend and independent of the "outside" API |
| 22 |
|
| 23 |
> 2) access to an internal download library built into portage (not wget |
| 24 |
> or some such). This would not only allow us to do basic downloading, |
| 25 |
> but also address new protocols that come later on. |
| 26 |
Excellent idea. afaik this idea is being implemented as "transports"? |
| 27 |
|
| 28 |
> 3) ability to access certain information regarding package environment |
| 29 |
> (CFLAGS, USE, etc.), which when trying to get this information, has been |
| 30 |
> stated as "unclean" in case the methods change later on (ie. pulling |
| 31 |
> from /var/pkg/db/category/package/USE I was told was a bad idea for some |
| 32 |
> reason). |
| 33 |
Does that differ from my idea for a generic config interface? |
| 34 |
|
| 35 |
> If portage can do it cleanly internally, an api should be able |
| 36 |
> to tap into that and give us something more solid to work with. This |
| 37 |
> should also help in getting rid of those pesky "Did my package get |
| 38 |
> compiled with this use flag" requests. |
| 39 |
> |
| 40 |
> 4) a searching API to look for certain packages. This sort of goes hand |
| 41 |
> in hand with #1, as it gives the ability for someone to get mysql |
| 42 |
> querying to acccess a mysql repository. |
| 43 |
I'd like to keep those two things separated. |
| 44 |
From a user p.o.v. the backend (flat files, db, pigeons) should be |
| 45 |
transparent. I think searching based on atoms, descriptions etc. would |
| 46 |
be best, the SQL interface might be documented separately ... |
| 47 |
|
| 48 |
> 5) Better info on SRC_URI's, including total size, downloaded size, |
| 49 |
> md5's, blah blah,etc etc. Somewhat goes hand in hand with #4. |
| 50 |
> |
| 51 |
> 6) An output api which would help in supporting gui displaying as well |
| 52 |
> as ncurses or anything else where one chooses that they want to put |
| 53 |
> stuff. Also, I'd like for a localization support feature in here |
| 54 |
> (localized strings basically). This would help in portage localization. |
| 55 |
erm ... |
| 56 |
that's not what the API does. |
| 57 |
The API only gives you access to portage internals. Your GUI gets |
| 58 |
wrapped around that so that any GUI uses the same communication |
| 59 |
primitives. |
| 60 |
|
| 61 |
Basically all your GUI needs to do should be: |
| 62 |
import portage |
| 63 |
blah=portage #blah is an instance of portage |
| 64 |
blah.init() # initialize that instance |
| 65 |
|
| 66 |
then work with that. |
| 67 |
|
| 68 |
|
| 69 |
> That's all that's on my mind for now. Please let me know if I need to |
| 70 |
> be clearer with some of my ideas. Please feel free to put your 2 |
| 71 |
> $country_coin_denomiation_value in to make this another meaningful |
| 72 |
> discussion. |
| 73 |
I think you should get the frontend and the backend separated. |
| 74 |
My GUI doesn't care about your SQL backend. Your SQL backend doesn't |
| 75 |
care about my OpenGL GUI. |
| 76 |
Otherwise I think your first rough draft looks good. |
| 77 |
|
| 78 |
wkr, |
| 79 |
Patrick |
Archives