1 |
Ok, since it was asked of by jstubbs, time to get some stuff rolling as |
2 |
to API requirements. |
3 |
|
4 |
1) repository can be more than just a standard abiding set of files. |
5 |
Maybe a custom repository, or a relational database. |
6 |
|
7 |
2) access to an internal download library built into portage (not wget |
8 |
or some such). This would not only allow us to do basic downloading, |
9 |
but also address new protocols that come later on. |
10 |
|
11 |
3) ability to access certain information regarding package environment |
12 |
(CFLAGS, USE, etc.), which when trying to get this information, has been |
13 |
stated as "unclean" in case the methods change later on (ie. pulling |
14 |
from /var/pkg/db/category/package/USE I was told was a bad idea for some |
15 |
reason). If portage can do it cleanly internally, an api should be able |
16 |
to tap into that and give us something more solid to work with. This |
17 |
should also help in getting rid of those pesky "Did my package get |
18 |
compiled with this use flag" requests. |
19 |
|
20 |
4) a searching API to look for certain packages. This sort of goes hand |
21 |
in hand with #1, as it gives the ability for someone to get mysql |
22 |
querying to acccess a mysql repository. |
23 |
|
24 |
5) Better info on SRC_URI's, including total size, downloaded size, |
25 |
md5's, blah blah,etc etc. Somewhat goes hand in hand with #4. |
26 |
|
27 |
6) An output api which would help in supporting gui displaying as well |
28 |
as ncurses or anything else where one chooses that they want to put |
29 |
stuff. Also, I'd like for a localization support feature in here |
30 |
(localized strings basically). This would help in portage localization. |
31 |
|
32 |
That's all that's on my mind for now. Please let me know if I need to |
33 |
be clearer with some of my ideas. Please feel free to put your 2 |
34 |
$country_coin_denomiation_value in to make this another meaningful |
35 |
discussion. |