| 1 |
On Wed, 19 Jul 2006 17:15:38 +0100 |
| 2 |
Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> wrote: |
| 3 |
|
| 4 |
> On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn" |
| 5 |
> <kevquinn@g.o> wrote: |
| 6 |
> | Things that package moves cause: |
| 7 |
> | 1) Dependencies throughout the tree have to be updated |
| 8 |
> |
| 9 |
> And? This isn't a breakage. |
| 10 |
|
| 11 |
It is however unnecessary inconvenience for the user, even assuming the |
| 12 |
support for moves is bug-free. |
| 13 |
|
| 14 |
> | 2) Current installations become inconsistent with respect to the |
| 15 |
> tree |
| 16 |
> |
| 17 |
> Uh, current installations become 'inconsistent' whenever anyone |
| 18 |
> changes *anything* in the tree. |
| 19 |
|
| 20 |
To a different degree. In the package move case, the inconsistency |
| 21 |
occurs even though nothing has really changed, in terms of what the |
| 22 |
packages actually do. |
| 23 |
|
| 24 |
> | 3) Binary packages go out-of-date |
| 25 |
> |
| 26 |
> So rebuild them. Binary packages go out of date whenever someone does |
| 27 |
> a version bump too. |
| 28 |
|
| 29 |
So your opinion is that it's fine to cause users to rebuild stuff even |
| 30 |
when the package itself hasn't changed? |
| 31 |
|
| 32 |
> | 4) Increased sync load |
| 33 |
> |
| 34 |
> Not really significant in comparison to, say, an arch team keywording |
| 35 |
> a new KDE or Gnome stable. |
| 36 |
|
| 37 |
The difference with KDE or Gnome going stable is that it actually |
| 38 |
provides something useful; i.e. an updated version of the packages that |
| 39 |
are presumably better in some way. Package moves do not improve what |
| 40 |
the package provides, at all, so you incur the pain for no gain. |
| 41 |
|
| 42 |
> | 5) Loss of history, unless the move is performed server-side (i.e. |
| 43 |
> | extra work for infra) |
| 44 |
> |
| 45 |
> History's in the ChangeLog. |
| 46 |
|
| 47 |
That's a fraction of what's in the CVS history, however. |
| 48 |
|
| 49 |
> | The key issue is that categories are semantically inadequate. |
| 50 |
> |
| 51 |
> That's no reason to use them improperly. |
| 52 |
|
| 53 |
I note you cherry-pick what to respond to. I explained how, without |
| 54 |
improper use (whatever that is), you just end up with a tug-of-war |
| 55 |
between herds about which category something should be in. |
| 56 |
|
| 57 |
> So again, you've *not* given any reasons to avoid sensible package |
| 58 |
> moves. |
| 59 |
|
| 60 |
Ah; now you're qualifying. What do you consider to be a sensible |
| 61 |
package move? I would define it as moves where the package is blatantly |
| 62 |
in the wrong category (e.g. a voip package being found in the app-text |
| 63 |
category) rather than moves where the package might be a little more |
| 64 |
appropriate for one category than another - especially where that |
| 65 |
judgement is subjective. |
| 66 |
|
| 67 |
-- |
| 68 |
Kevin F. Quinn |
Archives