On Thu, 20 Jul 2006 13:24:55 -0700 Brian Harring <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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. > > > > > > 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
signature.asc
Description: PGP signature
