1 |
On Thu, Jul 20, 2006 at 08:41:46PM +0200, Kevin F. Quinn wrote: |
2 |
> On Thu, 20 Jul 2006 00:37:47 -0700 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> |
5 |
> > On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote: |
6 |
> > > On Wed, 19 Jul 2006 17:15:38 +0100 |
7 |
> > > Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> wrote: |
8 |
> > > |
9 |
> > > > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn" |
10 |
> > > > <kevquinn@g.o> wrote: |
11 |
> > > > | Things that package moves cause: |
12 |
> > > > | 1) Dependencies throughout the tree have to be updated |
13 |
> > > > |
14 |
> > > > And? This isn't a breakage. |
15 |
> > > |
16 |
> > > It is however unnecessary inconvenience for the user, even assuming |
17 |
> > > the support for moves is bug-free. |
18 |
> > |
19 |
> > Think you're ignoring that proper categorization *is* useful to the |
20 |
> > user. One of the costs of that is moving when necessary. |
21 |
> |
22 |
> My main point is that "proper" categorisation is subjective. What |
23 |
> should be in net-voip for some people, should be in net-im for others |
24 |
> (since many packages provide functionality in both areas). Thus whether |
25 |
> or not it moves are necessary is subjective. |
26 |
|
27 |
How often does a package lie equally across multiple categories? I |
28 |
think your point (pulling probably fairly close figures out of the |
29 |
head) is relevant to all of 100 or so packages in the tree, out of |
30 |
11k. |
31 |
|
32 |
|
33 |
> > Sounds of it, you don't much care for categorizatin- that's fine, |
34 |
> > please keep in mind some people do find it a net gain to maintain the |
35 |
> > categorization however. |
36 |
> |
37 |
> I'm happy with the idea of categorisation in general, I do however think |
38 |
> that the categorisation in the tree as it stands is simply inadequate. |
39 |
|
40 |
Examples would be lovely- numerous examples specifically. Please keep |
41 |
in mind the tree holds (as of about 15 hours back) 11,212 packages. |
42 |
Pointing at one or two packages to label all categorization as |
43 |
inadequate won't suffice, going to need to clear at *least* 1% of the |
44 |
tree to back that assertion up. |
45 |
|
46 |
|
47 |
> > > > | 3) Binary packages go out-of-date |
48 |
> > > > |
49 |
> > > > So rebuild them. Binary packages go out of date whenever someone |
50 |
> > > > does a version bump too. |
51 |
> > > |
52 |
> > > So your opinion is that it's fine to cause users to rebuild stuff |
53 |
> > > even when the package itself hasn't changed? |
54 |
> > |
55 |
> > You're ignoring what fixpackages does. Ever noticed how it's far |
56 |
> > faster when you don't have buildpkgs enabled? ;) |
57 |
> |
58 |
> I certainly noticed how much time is lost when fixpackages chunters |
59 |
> through built packages to fix stuff up. |
60 |
|
61 |
My usual response to criticism of that sort applies- you know where |
62 |
the src is ;) |
63 |
|
64 |
Doing things *correctly* isn't always the same as doing things *fast*. |
65 |
Throwing correctness bits out in the name of speed is a no go (iow, |
66 |
fixpackages ought to be nonoptional). |
67 |
|
68 |
> > Again, you may not view categories as useful, but others may. |
69 |
> |
70 |
> My experience with categories as they stand, is that to find a package |
71 |
> whose location I don't already know I have to search all categories |
72 |
> anyway - it's certainly not possible to predict in which category a |
73 |
> package lives. |
74 |
|
75 |
Not much experience then. Your use scenario above is "I'm looking |
76 |
for a package", not "I'm trying to find packages in category x". |
77 |
|
78 |
Of course categories don't matter to you in your case- you're not |
79 |
*using* them. What others are talking about how ever is folks who |
80 |
*are* using categories- say to see if any new packages were added to |
81 |
games-strategy. |
82 |
|
83 |
|
84 |
> > > > So again, you've *not* given any reasons to avoid sensible package |
85 |
> > > > moves. |
86 |
> > > |
87 |
> > > Ah; now you're qualifying. What do you consider to be a sensible |
88 |
> > > package move? I would define it as moves where the package is |
89 |
> > > blatantly in the wrong category (e.g. a voip package being found in |
90 |
> > > the app-text category) rather than moves where the package might be |
91 |
> > > a little more appropriate for one category than another - |
92 |
> > > especially where that judgement is subjective. |
93 |
> > |
94 |
> > Arguement over how to categorize I'll gladly stay out of, although |
95 |
> > one comment- for pkgs that are (at the initial time of adding) one of |
96 |
> > a kind, creating a category for it's specific flavor doesn't make |
97 |
> > much sense. |
98 |
> |
99 |
> How to categorise is critical, if they are to have any meaning to |
100 |
> users. |
101 |
|
102 |
Even if a pkg is slightly miscategorized, it still is a fair bit more |
103 |
useful then having a flat namespace. |
104 |
|
105 |
> If you want to see if a package is in the tree, do you go |
106 |
> straight to it, or do you find yourself doing things like: |
107 |
> |
108 |
> ls -d /usr/portage/*/<packagename>* |
109 |
> |
110 |
> to find it? |
111 |
|
112 |
err... |
113 |
emerge -s <packagename> |
114 |
pquery <packagename> |
115 |
paludis -q <packagename> |
116 |
|
117 |
I'm honestly not really sure what point you're making there. |
118 |
~harring |