1 |
On Fri, 21 Jul 2006 01:05:20 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
|
4 |
> > >Unfortunately the category system is deeply embedded in portage |
5 |
> > >and the tree, so changing that system is simply not going to |
6 |
> > >happen, which is why I've stopped whinging about the semantic |
7 |
> > >inadequacy of the system. |
8 |
> > |
9 |
> > Instead of whinging about why the existing categories are bad, why |
10 |
> > not instead put forward an alternative (preferably with code, but a |
11 |
> > clear and consistently argued position would be a start) for |
12 |
> > something better? Otherwise, you *are* going to be ignored ... and |
13 |
> > with good reason. |
14 |
> |
15 |
> Just so we're clear, I probably will wedgie anyone who suggests |
16 |
> trying to extend the existing tree format with N categories per pkg- |
17 |
> sounds nice on paper, but it makes lookup a serious pita- |
18 |
> sys-apps/portage, we'll pretend it's actually located in sys-apps, |
19 |
> and it's also in category 'pkg-managers'. An atom states |
20 |
> 'pkg-managers/portage'; how does a pkg manager do a lookup for it? |
21 |
|
22 |
Since the names would be aliased, either reference would be fine i.e. a |
23 |
dep on pkg-managers/portage would be equivalent to sys-apps/portage. |
24 |
|
25 |
If it were to be implemented with symlinks (implying one entry is "real" |
26 |
and the others are aliases) the package manager just needs to |
27 |
canonicalise any symlinked CPs it comes across. |
28 |
|
29 |
Since we can't have symlinks in CVS, there are other ways it can be |
30 |
done; first thing that pops into my head is an "alias" package entry in |
31 |
the tree, where instead of ebuilds & files/ etc it would just contain a |
32 |
file "alias" with the category (and perhaps package name) of the aliased |
33 |
package. |
34 |
|
35 |
I would expect it to be non-trivial to implement in portage, since |
36 |
portage code has evolved for so long assuming that a package is in one |
37 |
category - I'm not saying portage code is bad, I'm just saying that |
38 |
much of it may have been implemented under that assumption and breaking |
39 |
it means testing lots of stuff. |
40 |
|
41 |
> Has to walk the entire tree... so if N category per pkg is going to |
42 |
> be proposed, need to preserve the fast lookup that's there now. |
43 |
|
44 |
I don't think the above ideas cause any substantial change to the |
45 |
amount of processing required. |
46 |
|
47 |
An advantage to this approach is that package moves just become aliases |
48 |
- existing stuff doesn't break yet you get the new categorisation as |
49 |
well. |
50 |
|
51 |
-- |
52 |
Kevin F. Quinn |