1 |
On Thu, 20 Jul 2006 09:05:03 +0200 "Kevin F. Quinn" |
2 |
<kevquinn@g.o> wrote: |
3 |
| On Wed, 19 Jul 2006 17:15:38 +0100 |
4 |
| Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> wrote: |
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 |
13 |
| the support for moves is bug-free. |
14 |
|
15 |
Eh? The only thing users see is packages where they'd expect them, |
16 |
which is very convenient. |
17 |
|
18 |
| > | 2) Current installations become inconsistent with respect to the |
19 |
| > tree |
20 |
| > |
21 |
| > Uh, current installations become 'inconsistent' whenever anyone |
22 |
| > changes *anything* in the tree. |
23 |
| |
24 |
| To a different degree. In the package move case, the inconsistency |
25 |
| occurs even though nothing has really changed, in terms of what the |
26 |
| packages actually do. |
27 |
|
28 |
Uh, changing KEYWORDS doesn't change what the packages actually do, but |
29 |
it does create an inconsistency. |
30 |
|
31 |
| > | 3) Binary packages go out-of-date |
32 |
| > |
33 |
| > So rebuild them. Binary packages go out of date whenever someone |
34 |
| > does a version bump too. |
35 |
| |
36 |
| So your opinion is that it's fine to cause users to rebuild stuff even |
37 |
| when the package itself hasn't changed? |
38 |
|
39 |
If they're one of the tree people for whom fixpackages is insufficient, |
40 |
then yes. |
41 |
|
42 |
| > | 4) Increased sync load |
43 |
| > |
44 |
| > Not really significant in comparison to, say, an arch team |
45 |
| > keywording a new KDE or Gnome stable. |
46 |
| |
47 |
| The difference with KDE or Gnome going stable is that it actually |
48 |
| provides something useful; i.e. an updated version of the packages |
49 |
| that are presumably better in some way. Package moves do not improve |
50 |
| what the package provides, at all, so you incur the pain for no gain. |
51 |
|
52 |
The gain is a more sensible tree. With the tree as big as it is, that's |
53 |
a very important consideration. |
54 |
|
55 |
| > | 5) Loss of history, unless the move is performed server-side (i.e. |
56 |
| > | extra work for infra) |
57 |
| > |
58 |
| > History's in the ChangeLog. |
59 |
| |
60 |
| That's a fraction of what's in the CVS history, however. |
61 |
|
62 |
Then start persuading people to keep better CHangeLogs. The CVS history |
63 |
is still around for when you really need it, of course. |
64 |
|
65 |
| > | The key issue is that categories are semantically inadequate. |
66 |
| > |
67 |
| > That's no reason to use them improperly. |
68 |
| |
69 |
| I note you cherry-pick what to respond to. I explained how, without |
70 |
| improper use (whatever that is), you just end up with a tug-of-war |
71 |
| between herds about which category something should be in. |
72 |
|
73 |
I'd call it "snipping out things that're irrelevant to the discussion |
74 |
at hand". Your personal dislike of categories has nothing to do with |
75 |
anything. We're talking about the tree and capabilities that're |
76 |
available, not the tree and capabilities you'd like. |
77 |
|
78 |
| > So again, you've *not* given any reasons to avoid sensible package |
79 |
| > moves. |
80 |
| |
81 |
| Ah; now you're qualifying. |
82 |
|
83 |
Well yes. It's to prevent you from countering with an absurd example |
84 |
where package moves are abused. Nobody really thinks we should be doing |
85 |
three hundred package moves every day, but I wouldn't put it past |
86 |
certain people to use an argument based around that to say that all |
87 |
package moves are bad... |
88 |
|
89 |
| What do you consider to be a sensible package move? |
90 |
|
91 |
One that makes the tree more consistent and easier to maintain. |
92 |
|
93 |
-- |
94 |
Ciaran McCreesh |
95 |
Mail : ciaran dot mccreesh at blueyonder.co.uk |
96 |
|
97 |
|
98 |
-- |
99 |
gentoo-dev@g.o mailing list |