1 |
On Mon, 24 Jul 2006 17:50:42 +0200 "Kevin F. Quinn" |
2 |
<kevquinn@g.o> wrote: |
3 |
| > As I said (and you seemed to have ignored), mandating tree access |
4 |
| > to use the vdb or a standalone binpkg repository == no go. |
5 |
| |
6 |
| I didn't ignore it - I didn't get it when you first said it. What |
7 |
| you're saying (?) is that to install a binpkg (for example), if the |
8 |
| tree is present it would resolve the category that the binpkg was |
9 |
| created under (that is now aliased) to the new category using the |
10 |
| alias data in the tree, and store stuff in the vdb under that new |
11 |
| category, purging out the entry in the vdb from the old category |
12 |
| (hence using tree data in the standalone case). Obviously this is |
13 |
| the correct behaviour when the tree is present. |
14 |
| |
15 |
| I'd suggest that in the absence of a tree, operations would assume no |
16 |
| aliasing (since all aliases at the time the vdb or binpkg were created |
17 |
| would already have been resolved), so the system state is still |
18 |
| consistent with the aliasing in force when the packages were built. |
19 |
|
20 |
Won't work, which is a large part of why this thing isn't as simple as |
21 |
you're assuming. The only way of handling it correctly is to keep track, |
22 |
with *each individual binary / vdb entry*, of all the names that |
23 |
have pointed to it at any given time between when it was created and |
24 |
current... |
25 |
|
26 |
Think through all the cases involving alias changing, removing etc. |
27 |
There're rather a lot of them, and a solution that handles all said |
28 |
cases sanely is unfortunately not going to be anything like |
29 |
straighforward. |
30 |
|
31 |
-- |
32 |
Ciaran McCreesh |
33 |
Mail : ciaran dot mccreesh at blueyonder.co.uk |
34 |
|
35 |
|
36 |
-- |
37 |
gentoo-dev@g.o mailing list |