1 |
On Tue, 18 Jul 2006 21:40:07 +0100 |
2 |
Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> wrote: |
3 |
|
4 |
> On Tue, 18 Jul 2006 21:18:22 +0200 "Kevin F. Quinn" |
5 |
> <kevquinn@g.o> wrote: |
6 |
> | > Uh, as far as I recall, you've yet to come up with any technical |
7 |
> | > explanation other than "it breaks one of my pet projects"... The |
8 |
> | > gains of consistency and manageability far outweigh the minor |
9 |
> | > inconvenience. |
10 |
> | |
11 |
> | Scan back through the -dev archives. We've been over this many |
12 |
> times, | in excruciating detail, not that it ever makes any |
13 |
> difference. |
14 |
> |
15 |
> Well that's kinda the point. You haven't. Every time it's just the |
16 |
> same vague "stuff breaks", without anything genuine value of stuff |
17 |
> that isn't someone's pet poorly written toy to back it up. |
18 |
|
19 |
Did you bother to search back through the archives? I know I've posted |
20 |
about this ad nauseum before. |
21 |
|
22 |
Things that package moves cause: |
23 |
1) Dependencies throughout the tree have to be updated |
24 |
2) Current installations become inconsistent with respect to the tree |
25 |
3) Binary packages go out-of-date |
26 |
4) Increased sync load |
27 |
5) Loss of history, unless the move is performed server-side (i.e. |
28 |
extra work for infra) |
29 |
|
30 |
fixpackages makes some effort to fix 3, but it's a band-aid solution. |
31 |
For a start, it assumes the binary packages are all present however |
32 |
binary packages may be archived off-line. fixpackages also takes a fair |
33 |
amount of resource to run, resource that end-users don't need to commit |
34 |
if we avoid unnecessary package moves. |
35 |
|
36 |
4 & 5 would be mitigated when/if we move to SVN. |
37 |
|
38 |
In my opinion moving packages from one category to another just causes |
39 |
unnecessary disruption to the tree - all relevant dependencies |
40 |
throughout the tree have to be altered, putting current installations |
41 |
out-of-date with respect to it. |
42 |
|
43 |
The key issue is that categories are semantically inadequate. Deciding |
44 |
which category a package fits into is subjective, frequently a package |
45 |
fits into many categories yet the category system insists that a |
46 |
package belong to one and only one category. |
47 |
|
48 |
Usually these big package moves occur when people want to align herds |
49 |
with categories, which is a waste of time - also it's daft as packages |
50 |
can sensibly belong to more than one herd. Unfortunately we see a lot |
51 |
of it in the tree. |
52 |
|
53 |
This week it's packages that have voip functionality that are being |
54 |
moved to net-voip. In six months time it'll be someone else wanting to |
55 |
move all packages with IM functionality into net-im. In herd-speak, |
56 |
these packages could easily belong to both the voip and im herds, |
57 |
should such exist; those providing c++ libraries could also belong to |
58 |
the cpp herd. This is useful, as the maintainers of those herds can |
59 |
each deal with issues in their field. It doesn't matter which category |
60 |
it's in. |
61 |
|
62 |
The only concrete thing categories give us is the ability to have two |
63 |
packages with the same upstream name without having to mangle the |
64 |
upstream name. |
65 |
|
66 |
Unfortunately the category system is deeply embedded in portage and the |
67 |
tree, so changing that system is simply not going to happen, which is |
68 |
why I've stopped whinging about the semantic inadequacy of the system. |
69 |
|
70 |
-- |
71 |
Kevin F. Quinn |