Re: [gentoo-dev] New category: net-voip

[Kevin F. Quinn]

On Thu, 20 Jul 2006 00:37:47 -0700
Brian Harring <ferringb@×××××.com> wrote:

> On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote:
> > On Wed, 19 Jul 2006 17:15:38 +0100
> > Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> wrote:
> >
> > > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
> > > <kevquinn@g.o> 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.
>
> Think you're ignoring that proper categorization *is* useful to the
> user.  One of the costs of that is moving when necessary.

My main point is that "proper" categorisation is subjective.  What
should be in net-voip for some people, should be in net-im for others
(since many packages provide functionality in both areas). Thus whether
or not it moves are necessary is subjective.

> Sounds of it, you don't much care for categorizatin- that's fine,
> please keep in mind some people do find it a net gain to maintain the
> categorization however.

I'm happy with the idea of categorisation in general, I do however think
that the categorisation in the tree as it stands is simply inadequate.

> > > | 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.
>
> Fundamentally the same thing however.  It's metadata changes in the
> pkg universe, people fixing missing deps on pkgs induce the same
> thing.

No, my point was that there are two types of change to the tree -
changes that make a functional difference, and changes that don't.
Most changes to the tree fall into the former; however package moves
fall into the latter.

> Thing to note however is that via fixpackages, the inconsistancy can
> be corrected (the example I gave above cannot be without a verbump of
> some sort).
>
>
> > > | 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?
>
> You're ignoring what fixpackages does.  Ever noticed how it's far
> faster when you don't have buildpkgs enabled? ;)

I certainly noticed how much time is lost when fixpackages chunters
through built packages to fix stuff up.  These moves are the main
reason I removed buildpkgs from FEATURES.  That was a while ago now -
Duncun suggests it's a lot faster now but I've not tried it recently.

> It goes through and rewrites the dependencies as needed.  So no,
> doesn't force a rebuild if the user is running with proper options
> (frankly an option that should be nonoptional).
>
>
> > > | 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.
>
> Again, you may not view categories as useful, but others may.

My experience with categories as they stand, is that to find a package
whose location I don't already know I have to search all categories
anyway - it's certainly not possible to predict in which category a
package lives.

> > > | 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.
>
> Back hand the herds then.  If they want to infight, spank their asses.
>
> Herds misbehaving doesn't mean everyone else is going to have a
> pissing match over the categorization of a pkg however- it shouldn't
> be used as an arguement _against_ proper categorization, since idiot
> infighting is a whole other problem.
>
>
> > > So again, you've *not* given any reasons to avoid sensible package
> > > moves.
> >
> > 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.
>
> Arguement over how to categorize I'll gladly stay out of, although
> one comment- for pkgs that are (at the initial time of adding) one of
> a kind, creating a category for it's specific flavor doesn't make
> much sense.

How to categorise is critical, if they are to have any meaning to
users.  If you want to see if a package is in the tree, do you go
straight to it, or do you find yourself doing things like:

ls -d /usr/portage/*/<packagename>*

to find it?

> Couple of months down the line?  # of pkgs that would fall into that
> categorization may warrant it, a scenario that does occur and is a
> bit relevant to net-voip.
>
> ~harring

-- 
Kevin F. Quinn