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

[Kevin F. Quinn]

On Thu, 20 Jul 2006 13:24:55 -0700
Brian Harring <ferringb@×××××.com> wrote:

> On Thu, Jul 20, 2006 at 08:41:46PM +0200, Kevin F. Quinn wrote:
> > 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.
>
> How often does a package lie equally across multiple categories?  I
> think your point (pulling probably fairly close figures out of the
> head) is relevant to all of 100 or so packages in the tree, out of
> 11k.

Pretty much anything in the sys-* categories, for a start.  Then
there's dev-libs - many packages provide libs and a simple app to use
them, so where do they go?  In *-libs or a category for the simple app?

> > > 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.
>
> Examples would be lovely- numerous examples specifically.  Please
> keep in mind the tree holds (as of about 15 hours back) 11,212
> packages. Pointing at one or two packages to label all categorization
> as inadequate won't suffice, going to need to clear at *least* 1% of
> the tree to back that assertion up.

I'm not going to waste time going through 11k+ packages to show you
that many packages provide functionality that applies to more than one
category; it seems obvious to me.  Some categories are better than
others - games-* for example, because those apps tend to be designed to
fit a category in the first place.  The problems arise when
categorisation occurs in more than one direction (e.g. sys-* overlaps
other categories) or when categorisation has become so tight that few
packages fit only in such categories (which is what I think is
happening with the net-im/voip categorisation).

> > > > > | 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.
>
> My usual response to criticism of that sort applies- you know where
> the src is ;)

My understanding is that the amount of time it takes to fix up binary
packages is down to having to unpack, tweak, then re-pack - the unpack
and re-pack are what consume the resource.  Any alternative would
involve changing the package format.

> Doing things *correctly* isn't always the same as doing things
> *fast*. Throwing correctness bits out in the name of speed is a no go
> (iow, fixpackages ought to be nonoptional).

I agree - however this for me is an argument to avoid package moves
unless the move is very necessary.

> > > 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.
>
> Not much experience then.  Your use scenario above is "I'm looking
> for a package", not "I'm trying to find packages in category x".

Huh?  That's my point - if I'm looking for a package I often don't know
what category it is until I find it.  Some categories are better than
others in this respect.  The point remains though that categories are
one-to-one, where as many packages provide functionality in more
than one area (one-to-many).  You can do one-to-many in a directory
structure by using links (symbolic or hard) - however CVS doesn't
support them, and the dep resolver won't cope with that at the moment
(it could be made to without too much trouble, I think).

> Of course categories don't matter to you in your case- you're not
> *using* them.  What others are talking about how ever is folks who
> *are* using categories- say to see if any new packages were added to
> games-strategy.
>
>
> > > > > 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.
>
> Even if a pkg is slightly miscategorized, it still is a fair bit more
> useful then having a flat namespace.

I'm not arguing for a flat namespace here, I'm arguing that package
moves should be kept to a minimum.

> > 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?
>
> err...
> emerge -s <packagename>
> pquery <packagename>
> paludis -q <packagename>
>
> I'm honestly not really sure what point you're making there.

The point is those search commands you list all do the same thing -
find a package from the package name without the category (or at least
can do - I don't know the exact behaviour of pquery or paludis). If you
knew the category you wouldn't need to search for it - however the fact
you have to search for it means the category isn't obvious - and that
means it probably falls naturally into more than one category.
The reason I use 'ls -d' rather than 'emerge -s' is that it's a _lot_
quicker.

-- 
Kevin F. Quinn