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. > 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
signature.asc
Description: PGP signature
