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. 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. > > | 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. 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? ;) 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. > > | 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. 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
pgpKRM0NKBb6U.pgp
Description: PGP signature
