1 |
On Sat, 22 Jul 2006 21:42:07 +0100 |
2 |
Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> wrote: |
3 |
|
4 |
> On Sat, 22 Jul 2006 18:04:10 +0200 "Kevin F. Quinn" |
5 |
> <kevquinn@g.o> wrote: |
6 |
> | If it were to be implemented with symlinks (implying one entry is |
7 |
> | "real" and the others are aliases) the package manager just needs to |
8 |
> | canonicalise any symlinked CPs it comes across. |
9 |
> |
10 |
> Not that simple. Think about installed packages, overlays and changing |
11 |
> aliases. The package manager would need to keep track of what aliases |
12 |
> were at any given time. |
13 |
|
14 |
Not if the aliases are resolved to the canonical CP when they are |
15 |
parsed. At any point in time, the dep resolver would be working with |
16 |
canonical CPs as they exist at that point, not what they were when the |
17 |
package was installed or the binpackage was built. |
18 |
|
19 |
> Then there're symlinks to outside the tree and |
20 |
|
21 |
Maybe I've misunderstood you here, but surely aliasing from inside the |
22 |
tree to outside it (e.g. to an overlay package not present in the |
23 |
primary tree) would not be sensible. |
24 |
|
25 |
> circular symlinks... There's a lot more too it than is initially |
26 |
> obvious. |
27 |
|
28 |
My understanding is that circular dependencies are not supported; the |
29 |
situation would be no different with aliasing, pretty much by |
30 |
definition if nothing else - all aliases should ultimately resolve to a |
31 |
real package, which they can't do if you allow circular aliases. |
32 |
|
33 |
> | Since we can't have symlinks in CVS, there are other ways it can be |
34 |
> | done; first thing that pops into my head is an "alias" package entry |
35 |
> | in the tree, where instead of ebuilds & files/ etc it would just |
36 |
> | contain a file "alias" with the category (and perhaps package name) |
37 |
> | of the aliased package. |
38 |
> |
39 |
> Files are cleaner than symlinks for other reasons too. Also allows the |
40 |
> opportunity of making 'deprecated' aliases that issue QA warnings. |
41 |
> |
42 |
> | > Has to walk the entire tree... so if N category per pkg is going |
43 |
> to | > be proposed, need to preserve the fast lookup that's there now. |
44 |
> | |
45 |
> | I don't think the above ideas cause any substantial change to the |
46 |
> | amount of processing required. |
47 |
> |
48 |
> Perhaps you should think. It's nowhere near as straight forward as you |
49 |
> claim. Which is not to say it's not doable, just that it's not doable |
50 |
> cheaply... |
51 |
|
52 |
I still don't see how, if aliases are canonicalised when they are |
53 |
parsed, the issue becomes more complex. Internally the package manager |
54 |
would always think in terms of the canonical CP, at which point it's |
55 |
not doing anything that it isn't already. |
56 |
|
57 |
-- |
58 |
Kevin F. Quinn |