1 |
On Sat, 22 Jul 2006 13:35:08 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
|
4 |
> On Sat, Jul 22, 2006 at 06:04:10PM +0200, Kevin F. Quinn wrote: |
5 |
> > On Fri, 21 Jul 2006 01:05:20 -0700 |
6 |
> > Brian Harring <ferringb@×××××.com> wrote: |
7 |
> > |
8 |
> > > > >Unfortunately the category system is deeply embedded in portage |
9 |
> > > > >and the tree, so changing that system is simply not going to |
10 |
> > > > >happen, which is why I've stopped whinging about the semantic |
11 |
> > > > >inadequacy of the system. |
12 |
> > > > |
13 |
> > > > Instead of whinging about why the existing categories are bad, |
14 |
> > > > why not instead put forward an alternative (preferably with |
15 |
> > > > code, but a clear and consistently argued position would be a |
16 |
> > > > start) for something better? Otherwise, you *are* going to be |
17 |
> > > > ignored ... and with good reason. |
18 |
> > > |
19 |
> > > Just so we're clear, I probably will wedgie anyone who suggests |
20 |
> > > trying to extend the existing tree format with N categories per |
21 |
> > > pkg- sounds nice on paper, but it makes lookup a serious pita- |
22 |
> > > sys-apps/portage, we'll pretend it's actually located in sys-apps, |
23 |
> > > and it's also in category 'pkg-managers'. An atom states |
24 |
> > > 'pkg-managers/portage'; how does a pkg manager do a lookup for it? |
25 |
> > |
26 |
> > Since the names would be aliased, either reference would be fine |
27 |
> > i.e. a dep on pkg-managers/portage would be equivalent to |
28 |
> > sys-apps/portage. |
29 |
> > |
30 |
> > If it were to be implemented with symlinks (implying one entry is |
31 |
> > "real" and the others are aliases) the package manager just needs to |
32 |
> > canonicalise any symlinked CPs it comes across. |
33 |
> > |
34 |
> > Since we can't have symlinks in CVS, there are other ways it can be |
35 |
> > done; first thing that pops into my head is an "alias" package |
36 |
> > entry in the tree, where instead of ebuilds & files/ etc it would |
37 |
> > just contain a file "alias" with the category (and perhaps package |
38 |
> > name) of the aliased package. |
39 |
> > |
40 |
> > I would expect it to be non-trivial to implement in portage, since |
41 |
> > portage code has evolved for so long assuming that a package is in |
42 |
> > one category - I'm not saying portage code is bad, I'm just saying |
43 |
> > that much of it may have been implemented under that assumption and |
44 |
> > breaking it means testing lots of stuff. |
45 |
> > |
46 |
> > > Has to walk the entire tree... so if N category per pkg is going |
47 |
> > > to be proposed, need to preserve the fast lookup that's there now. |
48 |
> > |
49 |
> > I don't think the above ideas cause any substantial change to the |
50 |
> > amount of processing required. |
51 |
> > |
52 |
> > An advantage to this approach is that package moves just become |
53 |
> > aliases |
54 |
> > - existing stuff doesn't break yet you get the new categorisation as |
55 |
> > well. |
56 |
> |
57 |
> A disadvantage being that without a tree, your graph is broken |
58 |
> (aliases live in the tree); this includes using strictly a bintree |
59 |
> (remote or otherwise). |
60 |
|
61 |
I don't get what you're talking about here; perhaps I'm missing |
62 |
something. I don't see why the deps can't be managed by canonicalising |
63 |
every reference as they are parsed. As you build the graph, the aliases |
64 |
disappear as they are canonicalised before they reach the graph. That |
65 |
way the only place aliases exist is in the portage tree itself - the |
66 |
package manager can forget about them once it has parsed the deps. |
67 |
|
68 |
Certainly trying to build the dependency tree without canonicalising |
69 |
aliases would be a mess; anyone trying to do it like that is asking |
70 |
for trouble. You want unique names for everything for which you're |
71 |
building the dependency tree. |
72 |
|
73 |
> Big disadvantage, hence why that approach was ignored last time it |
74 |
> was brought up. |
75 |
|
76 |
-- |
77 |
Kevin F. Quinn |