| 1 |
On Wed, Feb 18, 2004 at 10:46:24PM -0500, Jerry McBride wrote: |
| 2 |
|
| 3 |
Hi, |
| 4 |
|
| 5 |
> In retrospect you need not mandate a particular database, but having the |
| 6 |
> ability to plug portage into an sql compatible database engine would be a |
| 7 |
> dream. On the other, for the sake of simplicty, using something the likes |
| 8 |
> of bdb would be just as useful. Whatever you decide on using, it would HAVE |
| 9 |
> to be better than the current file system based method. |
| 10 |
|
| 11 |
I've been following your discussion for a couple of days, and have to |
| 12 |
say what I really like about portage is the possibility to alter the |
| 13 |
ebuilds without nearly one daemon running, that means for me the |
| 14 |
filesystem is ok, but on the other hand I'm working on a project which |
| 15 |
handles different documents which are available for download, all the |
| 16 |
data is stored in the fs in a portage like way but the metadata is |
| 17 |
stored in a db backend, so a (for the moment really bad) layout could be |
| 18 |
|
| 19 |
sql table: |
| 20 |
|
| 21 |
type | name | version | path |
| 22 |
------------------------------------------------- |
| 23 |
app-admin |addpatches | 0.2 | |
| 24 |
app-admin |aide | 0.8 | |
| 25 |
app-admin |aide | 0.9 | |
| 26 |
|
| 27 |
and so on (you get the idea). |
| 28 |
|
| 29 |
_but_ we are working on a wrapper script which |
| 30 |
|
| 31 |
a) gets the info from the filesystem, so if theres a new |
| 32 |
/usr/portage/$type_of_app/$app_name/$ebuild_version |
| 33 |
it would be automatically added to the database, this way you could |
| 34 |
easily modify ebuilds to your needs, add them to the tree (with a simple |
| 35 |
text editor) and still have a db backend. |
| 36 |
|
| 37 |
b) do the same thing the other way around |
| 38 |
|
| 39 |
of course emerge sync then should update both things and you would need |
| 40 |
an update script that syncs both, we are at the moment searching for a |
| 41 |
good way (in our system) to handle deleted ebuilds, because of the |
| 42 |
following reasons |
| 43 |
|
| 44 |
Should the package really be deleted (in the overlay dir for example) or |
| 45 |
was it just by mistake or was it deleted/moved by emerge sync |
| 46 |
|
| 47 |
The database could hold much more metadata and still portage (for users |
| 48 |
not using this feature) could be compatible with the old |
| 49 |
way since it would still work without the database. |
| 50 |
|
| 51 |
Just an idea and my 2cents :) |
| 52 |
|
| 53 |
Martin |
Archives