1 |
> There was a discussion a while ago (um, a couple years ago) about |
2 |
> removing categories completely and having a flat list of packages. The |
3 |
> argument against this was that the categories provide an easy way for |
4 |
> users (and developers) to see what is available in a given area. It was |
5 |
> not intended for categories to provide namespaces. |
6 |
|
7 |
I wasn't around a few years ago, but I've watched this conversation go |
8 |
back and forth from the previous one to the current. The following seems |
9 |
(to me) to be a good summary of the two leading points and |
10 |
counterpoints: |
11 |
|
12 |
|
13 |
Q: Shouldn't we list the two packages for an interactive choice when two |
14 |
or more are available? |
15 |
|
16 |
A: Interactive choice is against the design of emerge. We need to be |
17 |
able to use it more easily in scripts than that would allow. The best we |
18 |
can do is to generate an error with that information and let the user |
19 |
pick and re-run emerge. |
20 |
|
21 |
|
22 |
Q: Why don't we let categories define namespace? |
23 |
|
24 |
A: Because we've never used categories to define namespace. |
25 |
|
26 |
|
27 |
Is there a reason why emerge couldn't have a command line switch to |
28 |
cause it to deviate from its current behavior and give the user an |
29 |
interactive choice? I gather that the error-choice option is currently |
30 |
in the bugs db waiting for implementation, but a lot of users have |
31 |
seemed to like the idea of the interactive option, which I think a |
32 |
command line switch could integrate well. Is there a reason why this |
33 |
should be avoided? |
34 |
|
35 |
Also, although it isn't currently being done this way, is there a reason |
36 |
why (given the above changes) the categories shouldn't be used to define |
37 |
namespace? Unless I'm wrong, that would only involve a policy update, if |
38 |
a way of avoiding merging the wrong package in the case of a collision |
39 |
were in place. It seems like the intuitive way to go; most people seem |
40 |
to assume it works that way until they're told otherwise. Additionally, |
41 |
a lot of the discussion on this list of late (namely the Firebird issue) |
42 |
would've been avoided if that system were in place, and I imagine the |
43 |
same will be true of the future. Unless there's something I'm unaware |
44 |
of, this system would allow emerge to continue to function just as it |
45 |
currently does (besides the error on finding duplicate packages) while |
46 |
relieving a lot of naming headaches. |
47 |
|
48 |
|
49 |
- John Robinson |
50 |
|
51 |
-- |
52 |
|
53 |
Love justice; desire mercy. |
54 |
|
55 |
|
56 |
-- |
57 |
gentoo-dev@g.o mailing list |