1 |
On 2008-06-22, Daniel Pielmeier <daniel.pielmeier@××××××××××.com> wrote: |
2 |
|
3 |
>> 1. How does one know when not to do a sync/update so that one |
4 |
>> can avoid these problems? Is there a database broken or |
5 |
>> not-broken status? |
6 |
> |
7 |
> 1. You can not know before but you can monitor the irc channel |
8 |
> #gentoo-commits on freenode or the gentoo-commits mailing |
9 |
> list. So you know which changes are done to the portage |
10 |
> tree. Be careful this will cause heavy traffic to your |
11 |
> inbox. |
12 |
|
13 |
>> 2. Is there no way to "commit" a set of database changes so |
14 |
>> that the database doesn't have to be left in a broken |
15 |
>> state during moves? (Maybe I'm just spoiled using |
16 |
>> Subversion...) |
17 |
> |
18 |
> 2. I don't know if this is doable in one go. |
19 |
|
20 |
It's a rather fundamental feature of databases and revision |
21 |
control systems, so I guess I'd be a bit surprised that it |
22 |
can't be done that way. |
23 |
|
24 |
> The gentoo package maintainer adds the ebuild to its new |
25 |
> place and removes it from its old. When this is done he |
26 |
> changes the other ebuilds pointing to the old locations. He |
27 |
> also makes an entry in $PORTDIR/profiles/updates so the |
28 |
> /var/db/pkg is updated accordingly for already installed |
29 |
> packages. |
30 |
|
31 |
Wouldn't doing it the order below prevent problems? |
32 |
|
33 |
1) Add ebuild in new location. |
34 |
2) Change existing ebuilds to point to new location. |
35 |
3) Delete ebuild from old location. |
36 |
|
37 |
If even that can't be done, why not have a "working" copy of |
38 |
the database where such changes are made and then push |
39 |
non-broken snapshots of database out to the public servers? |
40 |
|
41 |
-- |
42 |
Grant |
43 |
|
44 |
-- |
45 |
gentoo-user@l.g.o mailing list |