1 |
On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote: |
2 |
> On Wed, 19 Jul 2006 17:15:38 +0100 |
3 |
> Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> wrote: |
4 |
> |
5 |
> > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn" |
6 |
> > <kevquinn@g.o> wrote: |
7 |
> > | Things that package moves cause: |
8 |
> > | 1) Dependencies throughout the tree have to be updated |
9 |
> > |
10 |
> > And? This isn't a breakage. |
11 |
> |
12 |
> It is however unnecessary inconvenience for the user, even assuming the |
13 |
> support for moves is bug-free. |
14 |
|
15 |
Think you're ignoring that proper categorization *is* useful to the |
16 |
user. One of the costs of that is moving when necessary. |
17 |
|
18 |
Sounds of it, you don't much care for categorizatin- that's fine, |
19 |
please keep in mind some people do find it a net gain to maintain the |
20 |
categorization however. |
21 |
|
22 |
|
23 |
> > | 2) Current installations become inconsistent with respect to the |
24 |
> > tree |
25 |
> > |
26 |
> > Uh, current installations become 'inconsistent' whenever anyone |
27 |
> > changes *anything* in the tree. |
28 |
> |
29 |
> To a different degree. In the package move case, the inconsistency |
30 |
> occurs even though nothing has really changed, in terms of what the |
31 |
> packages actually do. |
32 |
|
33 |
Fundamentally the same thing however. It's metadata changes in the |
34 |
pkg universe, people fixing missing deps on pkgs induce the same |
35 |
thing. |
36 |
|
37 |
Thing to note however is that via fixpackages, the inconsistancy can |
38 |
be corrected (the example I gave above cannot be without a verbump of |
39 |
some sort). |
40 |
|
41 |
|
42 |
> > | 3) Binary packages go out-of-date |
43 |
> > |
44 |
> > So rebuild them. Binary packages go out of date whenever someone does |
45 |
> > a version bump too. |
46 |
> |
47 |
> So your opinion is that it's fine to cause users to rebuild stuff even |
48 |
> when the package itself hasn't changed? |
49 |
|
50 |
You're ignoring what fixpackages does. Ever noticed how it's far |
51 |
faster when you don't have buildpkgs enabled? ;) |
52 |
|
53 |
It goes through and rewrites the dependencies as needed. So no, |
54 |
doesn't force a rebuild if the user is running with proper options |
55 |
(frankly an option that should be nonoptional). |
56 |
|
57 |
|
58 |
> > | 4) Increased sync load |
59 |
> > |
60 |
> > Not really significant in comparison to, say, an arch team keywording |
61 |
> > a new KDE or Gnome stable. |
62 |
> |
63 |
> The difference with KDE or Gnome going stable is that it actually |
64 |
> provides something useful; i.e. an updated version of the packages that |
65 |
> are presumably better in some way. Package moves do not improve what |
66 |
> the package provides, at all, so you incur the pain for no gain. |
67 |
|
68 |
Again, you may not view categories as useful, but others may. |
69 |
|
70 |
|
71 |
> > | The key issue is that categories are semantically inadequate. |
72 |
> > |
73 |
> > That's no reason to use them improperly. |
74 |
> |
75 |
> I note you cherry-pick what to respond to. I explained how, without |
76 |
> improper use (whatever that is), you just end up with a tug-of-war |
77 |
> between herds about which category something should be in. |
78 |
|
79 |
Back hand the herds then. If they want to infight, spank their asses. |
80 |
|
81 |
Herds misbehaving doesn't mean everyone else is going to have a |
82 |
pissing match over the categorization of a pkg however- it shouldn't |
83 |
be used as an arguement _against_ proper categorization, since idiot |
84 |
infighting is a whole other problem. |
85 |
|
86 |
|
87 |
> > So again, you've *not* given any reasons to avoid sensible package |
88 |
> > moves. |
89 |
> |
90 |
> Ah; now you're qualifying. What do you consider to be a sensible |
91 |
> package move? I would define it as moves where the package is blatantly |
92 |
> in the wrong category (e.g. a voip package being found in the app-text |
93 |
> category) rather than moves where the package might be a little more |
94 |
> appropriate for one category than another - especially where that |
95 |
> judgement is subjective. |
96 |
|
97 |
Arguement over how to categorize I'll gladly stay out of, although one |
98 |
comment- for pkgs that are (at the initial time of adding) one of a |
99 |
kind, creating a category for it's specific flavor doesn't make much |
100 |
sense. |
101 |
|
102 |
Couple of months down the line? # of pkgs that would fall into that |
103 |
categorization may warrant it, a scenario that does occur and is a bit |
104 |
relevant to net-voip. |
105 |
|
106 |
~harring |