List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Wed, 19 Jul 2006 17:15:38 +0100
Ciaran McCreesh <ciaran.mccreesh@...> wrote:
> On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
> <firstname.lastname@example.org> 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.
> | 2) Current installations become inconsistent with respect to the
> 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.
> | 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?
> | 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.
> | 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.
> | 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.
> So again, you've *not* given any reasons to avoid sensible package
Ah; now you're qualifying. What do you consider to be a sensible
package move? I would define it as moves where the package is blatantly
in the wrong category (e.g. a voip package being found in the app-text
category) rather than moves where the package might be a little more
appropriate for one category than another - especially where that
judgement is subjective.
Kevin F. Quinn