| 1 |
Hi, |
| 2 |
|
| 3 |
I start to like this thread. I'm using gentoo in my company and would |
| 4 |
appreciate (even help, if possible) to realize a sql-backend for |
| 5 |
portage. |
| 6 |
At the moment I export the whole portage-tree to all my clients from one |
| 7 |
server to keep the used disk space for distfiles as low as possible and |
| 8 |
to |
| 9 |
prevent having all workstations emerge-sync by there own. If there would |
| 10 |
be |
| 11 |
a (imho the "old" portage style is ok for single machines, so I say |
| 12 |
having a |
| 13 |
database as portage-backend is a nice-to-have feature) sql-server |
| 14 |
keeping |
| 15 |
the portage-database then maybe clients don't even need to have the |
| 16 |
/usr/portage - tree. |
| 17 |
|
| 18 |
But how do the workstations get the distfiles in this setup? Downloading |
| 19 |
them on every workstation is _not_ a good solution, if its on a |
| 20 |
corporate network or at least "trusted" and storing them in the database |
| 21 |
too isn't good either so there needs to be something to dispatch the |
| 22 |
request (maybe an on-demand-process to deliver requested distfiles). I |
| 23 |
think the whole portage should get a more network-compatible style for |
| 24 |
setups like mine, what would make it more easier to integrate and |
| 25 |
maintain state even with a large scale of clients. |
| 26 |
|
| 27 |
Cheers |
| 28 |
|
| 29 |
Felix |
| 30 |
|
| 31 |
|
| 32 |
On Wed, Feb 18, 2004 at 10:46:24PM -0500, Jerry McBride wrote: |
| 33 |
|
| 34 |
Hi, |
| 35 |
|
| 36 |
> In retrospect you need not mandate a particular database, but having |
| 37 |
the |
| 38 |
> ability to plug portage into an sql compatible database engine would |
| 39 |
be a |
| 40 |
> dream. On the other, for the sake of simplicty, using something the |
| 41 |
likes |
| 42 |
> of bdb would be just as useful. Whatever you decide on using, it would |
| 43 |
HAVE |
| 44 |
> to be better than the current file system based method. |
| 45 |
|
| 46 |
I've been following your discussion for a couple of days, and have to |
| 47 |
say what I really like about portage is the possibility to alter the |
| 48 |
ebuilds without nearly one daemon running, that means for me the |
| 49 |
filesystem is ok, but on the other hand I'm working on a project which |
| 50 |
handles different documents which are available for download, all the |
| 51 |
data is stored in the fs in a portage like way but the metadata is |
| 52 |
stored in a db backend, so a (for the moment really bad) layout could be |
| 53 |
|
| 54 |
sql table: |
| 55 |
|
| 56 |
type | name | version | path |
| 57 |
------------------------------------------------- |
| 58 |
app-admin |addpatches | 0.2 |
| 59 |
| |
| 60 |
app-admin |aide | 0.8 |
| 61 |
| |
| 62 |
app-admin |aide | 0.9 |
| 63 |
| |
| 64 |
|
| 65 |
and so on (you get the idea). |
| 66 |
|
| 67 |
_but_ we are working on a wrapper script which |
| 68 |
|
| 69 |
a) gets the info from the filesystem, so if theres a new |
| 70 |
/usr/portage/$type_of_app/$app_name/$ebuild_version |
| 71 |
it would be automatically added to the database, this way you could |
| 72 |
easily modify ebuilds to your needs, add them to the tree (with a simple |
| 73 |
text editor) and still have a db |
| 74 |
backend. |
| 75 |
|
| 76 |
b) do the same thing the other way around |
| 77 |
|
| 78 |
of course emerge sync then should update both things and you would need |
| 79 |
an update script that syncs both, we are at the moment searching for a |
| 80 |
good way (in our system) to handle deleted ebuilds, because of the |
| 81 |
following reasons |
| 82 |
|
| 83 |
Should the package really be deleted (in the overlay dir for example) or |
| 84 |
was it just by mistake or was it deleted/moved by emerge sync |
| 85 |
|
| 86 |
The database could hold much more metadata and still portage (for users |
| 87 |
not using this feature) could be |
| 88 |
compatible with the old |
| 89 |
way since it would still work without the database. |
| 90 |
|
| 91 |
Just an idea and my 2cents :) |
| 92 |
|
| 93 |
Martin |
Archives