1 |
Denis Dupeyron wrote: |
2 |
|
3 |
> On Tue, Feb 3, 2009 at 11:47 AM, George Shapovalov <george@g.o> |
4 |
> wrote: |
5 |
>> Besides, in my opinion, the ability to see "what's there" in at least |
6 |
>> minimally categorized way without having to resort to using some special |
7 |
>> tools or going to some website is worht something. In this vain I was |
8 |
>> proposing going the opposite direction - to allow arbitrary nesting of |
9 |
>> categories, like going sci-math -> sci/math and deeper (then packages |
10 |
>> would naturally be specified by "FQEN" - fully qualified ebuild names). |
11 |
>> Its not like tree walker would be the most complex part of code in |
12 |
>> portage.. |
13 |
> |
14 |
> Actually we'd want both tags and nesting. They don't address the same |
15 |
> issue. |
16 |
> |
17 |
> Arbitrary nesting of categories allows better management and storing |
18 |
> of ebuilds. It could also allow a meta-ebuild to depend on a whole |
19 |
> subcategory to ease maintenance of said meta-ebuild. It's more a |
20 |
> developer's feature. |
21 |
> |
22 |
That sounds very similar to sets? Sorry if I'm missing something obvious, |
23 |
but I thought sets were used with kde4; if they are unavailable to the |
24 |
ebuild author, perhaps a suitably-defined extension (for in-tree sets) |
25 |
might be useful? |
26 |
The obvious advantage being that they are not tied to a specific category, |
27 |
ofc; could you expand a bit on 'better management and storing'? |
28 |
|
29 |
> Tags allow ebuilds to appear as being pertinent to more |
30 |
> (sub-)categories than just the one they're stored into. It may help |
31 |
> some of us locate packages they need in a better and/or faster way. |
32 |
> It's more of a user's feature. |
33 |
> |
34 |
Tags sound cool. I'm opposed to losing the current single flat category |
35 |
schema, fwtw, unless it enables something majorly-useful. It's *way* better |
36 |
than other distros (I am deadset against losing all categorisation) and |
37 |
still nice and immediate. |