On 7/19/06, Kevin F. Quinn <[EMAIL PROTECTED]> wrote:
In my opinion moving packages from one category to another just causes unnecessary disruption to the tree - all relevant dependencies throughout the tree have to be altered, putting current installations out-of-date with respect to it.
Some other folk hold a different opinion. It's both perfectly natural and desirable for packages to migrate out of -misc type categories into more targetted categories over time. We've done it in the past, and it's something we need to be able to continue to do in the future. It helps folks look for things when they don't know the name of what they're looking for, and it stops -misc type categories from becoming dumping grounds.
The key issue is that categories are semantically inadequate.
Do you have any evidence to show that this is a widely-held opinion? Have you done any research amongst the wider user community to find out how they view categories?
Deciding which category a package fits into is subjective, frequently a package fits into many categories yet the category system insists that a package belong to one and only one category.
All classification systems are subjective, imperfect, and prone to change over time. Portage's is no worse than any other in this respect. (What is worse is the way Portage copes with change ... I agree with Mike here, we should be fixing our tools, rather than being artificially restricted by them).
Usually these big package moves occur when people want to align herds with categories, which is a waste of time - also it's daft as packages can sensibly belong to more than one herd. Unfortunately we see a lot of it in the tree.
You think it's daft, but that's just one perspective. What would you prefer? A tree where packages never ever move category? Christ, if we followed that dogma, then categories really would be useless, because we'd have far too many packages filed in the wrong place, or in general catchall -misc type categories. I think it's more important that the tree can be flexible, and can change structure over time.
This week it's packages that have voip functionality that are being moved to net-voip. In six months time it'll be someone else wanting to move all packages with IM functionality into net-im. In herd-speak, these packages could easily belong to both the voip and im herds, should such exist; those providing c++ libraries could also belong to the cpp herd. This is useful, as the maintainers of those herds can each deal with issues in their field. It doesn't matter which category it's in.
It seems a bit odd that a language herd like cpp (using your own example) would maintain a package just because the package itself is written in cpp, irrespective of what the package actually does. For example, the PHP herd is focused on packages that provide the PHP language and it's supporting infrastructure ... not on applications that are written in PHP. Those are left to other herds, who are more expert in the problems that those applications solve.
The only concrete thing categories give us is the ability to have two packages with the same upstream name without having to mangle the upstream name.
Not true. They provide us with an organisational ability too, whether its grouping packages to ensure people don't dump stuff in the tree (dev-perl being the classic example here), grouping packages by origin (gnome-*) or by common purpose (sys-fs). If a user needs something, but doesn't know which package they want, they can look inside the relevant category, and see what their choices are. In fact, categories do not give us the complete ability to have two packages with the same upstream name in the tree ... because binary packages do not support category names at all.
Unfortunately the category system is deeply embedded in portage and the tree, so changing that system is simply not going to happen, which is why I've stopped whinging about the semantic inadequacy of the system.
Instead of whinging about why the existing categories are bad, why not instead put forward an alternative (preferably with code, but a clear and consistently argued position would be a start) for something better? Otherwise, you *are* going to be ignored ... and with good reason. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
