On Thu, 20 Jul 2006 09:05:03 +0200 "Kevin F. Quinn"
<[EMAIL PROTECTED]> wrote:
| On Wed, 19 Jul 2006 17:15:38 +0100
| Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
| > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
| > <[EMAIL PROTECTED]> wrote:
| > | Things that package moves cause:
| > | 1) Dependencies throughout the tree have to be updated
| > 
| > And? This isn't a breakage.
| 
| It is however unnecessary inconvenience for the user, even assuming
| the support for moves is bug-free.

Eh? The only thing users see is packages where they'd expect them,
which is very convenient.

| > | 2) Current installations become inconsistent with respect to the
| > tree
| > 
| > Uh, current installations become 'inconsistent' whenever anyone
| > changes *anything* in the tree.
| 
| To a different degree.  In the package move case, the inconsistency
| occurs even though nothing has really changed, in terms of what the
| packages actually do.

Uh, changing KEYWORDS doesn't change what the packages actually do, but
it does create an inconsistency.

| > | 3) Binary packages go out-of-date
| > 
| > So rebuild them. Binary packages go out of date whenever someone
| > does a version bump too.
| 
| So your opinion is that it's fine to cause users to rebuild stuff even
| when the package itself hasn't changed?

If they're one of the tree people for whom fixpackages is insufficient,
then yes.

| > | 4) Increased sync load
| > 
| > Not really significant in comparison to, say, an arch team
| > keywording a new KDE or Gnome stable.
| 
| The difference with KDE or Gnome going stable is that it actually
| provides something useful; i.e. an updated version of the packages
| that are presumably better in some way.  Package moves do not improve
| what the package provides, at all, so you incur the pain for no gain.

The gain is a more sensible tree. With the tree as big as it is, that's
a very important consideration.

| > | 5) Loss of history, unless the move is performed server-side (i.e.
| > | extra work for infra)
| > 
| > History's in the ChangeLog.
| 
| That's a fraction of what's in the CVS history, however.

Then start persuading people to keep better CHangeLogs. The CVS history
is still around for when you really need it, of course.

| > | The key issue is that categories are semantically inadequate.
| > 
| > That's no reason to use them improperly.
| 
| I note you cherry-pick what to respond to.  I explained how, without
| improper use (whatever that is), you just end up with a tug-of-war
| between herds about which category something should be in.

I'd call it "snipping out things that're irrelevant to the discussion
at hand". Your personal dislike of categories has nothing to do with
anything. We're talking about the tree and capabilities that're
available, not the tree and capabilities you'd like.

| > So again, you've *not* given any reasons to avoid sensible package
| > moves.
| 
| Ah; now you're qualifying.

Well yes. It's to prevent you from countering with an absurd example
where package moves are abused. Nobody really thinks we should be doing
three hundred package moves every day, but I wouldn't put it past
certain people to use an argument based around that to say that all
package moves are bad...

|  What do you consider to be a sensible package move?

One that makes the tree more consistent and easier to maintain.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Reply via email to