Gentoo Archives: gentoo-dev

From: Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] New category: net-voip
Date: Mon, 24 Jul 2006 16:33:17
Message-Id: 20060724173057.6aeb2b37@snowdrop.home
In Reply to: Re: [gentoo-dev] New category: net-voip by "Kevin F. Quinn"
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